DRAFT — DRAFT — DRAFT — DRAFT — DRAFT


IESG Narrative Minutes

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

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

Corrections from:

1 Administrivia

  1. Roll Call 1133 EST 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. OSPFv3 as a PE-CE routing protocol (Proposed Standard)
    draft-ietf-l3vpn-ospfv3-pece-10
    Token: Stewart Bryant
    Note: Ben Niven-Jenkins (ben@niven-jenkins.co.uk) is the Document Shepherd
    Discusses/comments (from ballot 3233):
    1. Jari Arkko: Comment [2011-12-14]:
      +1 to comments from Fred Baker and Dan Romascanu
    2. Stephen Farrell: Comment [2011-12-13]:
      - Who's the document shepherd? Tracker note says Ben, iesg writeup says Danny. Probably a typo somewhere or a change, but might be worth fixing.
      - The abstract is confusing. It says "We had BGP/MPLS for IPv4; then we added IPv6; then we added OSPFv2 and now in this document, we add OSPFv3." Telling the reader about IPv4/IPv6 just seems distracting here.
      - NLRI & NSSA not expanded on 1st use.
      - Is it safe to use a NULL domain ID? If I do that then an incoming message can easily be confusing?
      - Section 7 refers to rfc 4659 section 11 and 4577 section 6.
      4659 section 11 refers to 2545 section 5 and 4364 section 13.
      4577 refers to 4364 and 4365.
      2545 says "nothing new here."
      4364 is updated by 4577, 4684 and 5462.
      4577 says "cryptographic authentication" SHOULD be used and MUST be implemented but doesn't say what "cryptographic authentication" really means.
      I stopped following the breadcrumbs at that point;-)
      Can't we do this better and simpler?
    3. Dan Romascanu: Comment [2011-12-14]:
      Fred Baker made in his OPS-DIR review a couple of comments which are not show stoppers but deserve being answered and clarified if necessary in the text:
      1. The introduction mentions the use of OSPFv2 for IPv4 and OSPFv3 for IPv6. With the advent of OSPFv3 address families, mentioned in section 6, it is possible to use OSPFv3 for IPv4, enabling one protocol and one configuration to be used for both network layer protocols. I would expect that this might be a useful thing to comment on in the introduction.
      2. The one question I was left asking was why the document mentioned MPLS in 20 places but did nothing with MPLS other than mention that it was used in BGP/MPLS VPNs. The routing technology could just as easily be used on any other PE-CE link; the point is that it is between an OSPFv3 instance in the PE and a correspondent on the CE router, enabling a customer to communicate with an upstream in a manner that enabled the upstream to trust routing information without the customer needing to obtain an AS number and operate a BGP configuration. That's not an impediment; the document only chose to specify that configuration. But the narrowness of specification left me puzzled.

    Telechat:

  2. RPL Option for Carrying RPL Information in Data-Plane Datagrams (Proposed Standard)
    draft-ietf-6man-rpl-option-06
    Token: Jari Arkko
    Note: Brian Haberman (brian@innovationslab.net) is the document shepherd.
    Discusses/comments (from ballot 3770):
    1. Jari Arkko: Comment [2011-12-01]:
      Sorry, posted the IANA issue in wrong tracker window...
    2. Ralph Droms: Discuss [2011-11-29]:
      1. The first sentence of section 4: "Datagrams sent between RPL routers MUST include a RPL Option or RPL Source Route Header ([I-D.ietf-6man-rpl-routing-header]) and MAY include both."
      Under what circumstances would a RPL router include an SRH but not a RPL Option?
      2. This issue requires a little clarification before I can provide an actionable Discuss issue. Is it possible to deploy RPL in a network in which not all of the nodes in the network participate in RPL? E.g., can there be "leaf" nodes, the equivalent of hosts, that do not participate in RLL and that exchange datagrams with immediate neighbors that are RPL routers? There is a hint that such a deployment is anticipated in the phrase "attachment router" in section 4. If so, I think there needs to be additional text similar to that in section 5 describing how a RPL router must ensure that it doesn't forward a datagram containing a RPL Option to a non-RPL leaf node.
    3. Adrian Farrel: Comment [2011-11-30]:
      I have no objection to the publication of this document, but I have a umber of questions/nits that I hope you will consider.
      Section 1: "To that end, this document proposes a new IPv6 option,"
      s/proposes/defines/
      Setion 2: "Every RPL router along a packet's delivery path processes and updates the RPL Option. If the received packet does not already contain a RPL Option, the RPL router must insert a RPL Option before forwarding it to another RPL router."
      Surely that means that the absence of the option indicates a defect in the upstream router. This issue is also present in section 4 where there is some flexibility about whether to include the RPL Option, but no guidance.
      Section 3: Please consider using RFC2119 language (e.g. "shall")
      Section 3: "Nodes that do not understand the RPL Option MUST discard the packet."
      You cannot state this in this way. Nodes that do not understand the option will not implement this spec!
      You probably simply need: "As defined in [foo] nodes that do not understand an option on a received packet MUST discard the packet."
      Sections 3 and 7: Please check "sub-TLV" and "TLV". I think you have used them interchangeably.
    4. Stephen Farrell: Comment [2011-12-14]:
      (blank)
    5. Russ Housley: Comment [2011-11-28]:
      The Gen-ART Review by Joel Halpern on 22-Nov-2011 included a suggestion for improved clarity. Please consider it.
      While calling a bit the O bit does not appear unreasonable, I note that when looking at the packet form, the difference between the O bit and the mbz bits marked as 0 is small, and a likely source of confusion for the reader.
    6. Robert Sparks: Comment [2011-11-29]:
      Please double-check the first paragraph of section 4 to make sure that "ICMPv6 errors generated by inserting the RPL option" is really what you mean to say - are you talking about errors that resulted from inserting the option itself, or possibly other ICMP errors that might result from other data in the tunnel header?
    7. Sean Turner: Comment [2011-11-30]:
      I support Stephen's discuss.

    Telechat:

  3. A Location Dereferencing Protocol Using HELD (Proposed Standard)
    draft-ietf-geopriv-deref-protocol-04
    Token: Robert Sparks
    Note: Richard Barnes (rbarnes@bbn.com) is the document shepherd.
    Discusses/comments (from ballot 3968):
    1. Jari Arkko: Comment [2011-12-15]:
      Maybe I missed it or it is discussed in some other document, but I felt the document did not describe some basic properties of local references. For instance, if I ask for my location and then pass it on to someone else, is the resulting dereferenced location my location at the time of the request, or my current location? Devices can move...
    2. Stephen Farrell: Discuss [2011-12-12]:
      #1 The draft is (a little) inconsistent about the requirement to *use* TLS. Section 1, end of 3rd para says this "requires use of TLS", but elsewhere (e.g. section 4, 2nd para) you say that this defines how to use "http:" URIs and the security considerations says only that TLS is "strongly RECOMMENDED." I'd prefer it all to say that you MUST use TLS always, but it at least needs to be consistent doesn't it? This should be an easy fix, I guess.
      #2 What, if any, form(s) of TLS server auth are required to be used when TLS is used? Would it be right to say a client MUST NOT not offer anonymous ciphersuites in the client hello? i.e the TLS_*_anon_* ciphersuites. (Just checking in case that hadn't been considered. If it already was and there's a reason to allow anon ciphersuites that's ok but would be worth explaining.)
    3. Stephen Farrell: Comment [2011-12-12]:
      - I expected to see some mention of single-use URIs here. Is there no use-case for those? It might help a bit given the possession-is-authorizaiton model? (But it'd also conflict with other use-cases maybe.)
      - s3.1, maybe s/is constructed/MUST be constructed/ such that it is hard to guess?
      - what are the "other measures" mentioned in the 2nd last para of 3.1?
    4. Pete Resnick: Discuss [2011-12-14]:
      3.2/3.3: I cannot see how this protocol can be interoperable unless you commit to a particular policy mechanism and format, not just a "possible format" [3.2] or a mechanism "such as those described in [I-D.ietf-geopriv-policy]". It seems to me that ietf-geopriv-policy should be a normative reference in this document, not an informative one, and these two sections should be written to normatively reference it.
    5. Pete Resnick: Comment [2011-12-14]:
      Section 1: Lots of redundant text. Could use an edit. A single paragraph is probably sufficient. I also find the diagram not terribly useful in the intro.
      Section 3: I actually found this discussion rather confusing and unnecessary. "Authorization by Posession" is often equivalent to no authorization at all. For certain resources that require no particular protection, there needn't be any obscuration by "hard to guess" URIs, and there needn't be a Rule Maker in existence at all. On the flip side, Authorization via Access Control needn't involve a policy document at all: regular HTTP authenthication could be used with a username and password, and access control can be handled entirely by the HTTP server, again without a Rule Maker. (Of course, in each case there is theoretically a "Rule Maker", but that is so theoretical as to make the entity of little use conceptually.) No matter the authorization and authentication used, Posession is still required, so I don't see that as a useful concept.
      I would be happy if this section simply eliminated the concept of "Authorization by Posession" and simply talked about different authorization and authentication methods. I think it would also be fine to leave this entire discussion to the policy document. But at the very least, I think you should mention that Authorization by Posession does not require a Rule Maker or a policy or making URIs hard to guess, though those are options to make access to location information more controlled.
    6. Peter Saint-Andre: Comment [2011-12-13]:
      The AppsDir review by Ted Hardie raised several minor issues, which deserve a response.
      A number of terms are re-used from RFC 3693 and RFC 5808; it would be helpful to cite those specifications in Section 2.
      Although Section 3 says that "no authentication framework is provided", it's not true that authentication cannot be performed (e.g., if HTTP is used to communicate with the LIS/LS then HTTP authentication can be used). The text here is not entirely consistent with the later text in Section 3.3 ("A Location Server MAY support an authentication mechanism that enables identity-based authorization policies to be used") and similar text in Section 4.
      It would be appropriate to say something about leakage of location URIs (which could happen outside the TLS-protected channel between the Target and the Location Recipient -- URIs have a tendency to leak). RFC 5808 has some text about this, and perhaps you could simply point there.
    7. Sean Turner: Discuss [2011-12-14]:
      1) This is along the same lines as Stephen's #1.
      s3.1: Just to make sure I understand Authorization by Possession could just as easily have been called Authorization by Obscure URI? These seems like security through obscurity.
      Also, shouldn't there be some kind of statement like at a minimum: "The use of this model SHOULD involve the use of TLS?"
      Actually based on s4 shouldn't that be a MUST?
      s4 contains the following: "The Location Recipient establishes a connection to the LS, as described in [RFC2818]. The TLS ciphersuite TLS_NULL_WITH_NULL_NULL MUST NOT be used. The LS MUST be authenticated to ensure that the correct server is contacted."
      I read that as HTTPS MUST be used. If that is how you intended it, can't you just say that instead?
      s6 says s4 says it's strong RECOMMENDED, but I don't see that in s4.
    8. Sean Turner: Comment [2011-12-14]:
      1) Figure 2: Shouldn't the two figures in the geo-priv drafts match?
      2) s3.1: Isn't it c8 in RFC 5808: "(see C9 of [RFC5808])"
      3) s3.1: Isn't this true only when you don't use S/MIME: "Use of authorization by possession location URIs in a hop-by-hop protocol such as SIP [RFC3261] adds the possibility of on-path adversaries."
      4) s3.2: strike the a: "In contrast to authorization by possession, possession of a this form of location URI does not imply authorization."
      5) s3.2: I think you need to work something about authorization by access control being based on an authentication mechanism. You mention in s3 and then again in s3.3, but it seems like it needs to be included in s3.2. I kept thinking .. because … after the first sentence. Maybe:
      "Use of explicit access control provides a Rule Maker greater control over the behaviour of an LS because it determines access based on individual Location Recipients."
      or something like that.
      6) s3.3: In the first two paragraphs of s3.3, I think you're trying to say this:
      "This document does not describe a specific authentication mechanism; therefore, the authorization by access control model is not an option. Instead, this document uses the authorization by possession model."
      The existing two paragraphs seemed little wordy.

    Telechat:

  4. Location Configuration Extensions for Policy Management (Proposed Standard)
    draft-ietf-geopriv-policy-uri-04
    Token: Robert Sparks
    Note: Alissa Cooper (acooper@cdt.org) is the document shepherd.
    Discusses/comments (from ballot 3978):
    1. Jari Arkko: Discuss [2011-12-15]:
      I will probably clear this after some discussion in the IESG tonight, and let Stephen hold his Discuss (item #5 in particular).
      However, I am concerned that the document provides an authorization-by-possession model for clients to access their policies, delivers the policy URLs in the same DHCP and XML structures as other location URLs, and also acknowledges that there is a legitimate need for other entities to access policies:
      "This document does not describe how policy might be provided to entities other than for location configuration, for example, in responses to dereferencing requests [I-D.ietf-geopriv-deref-protocol] or requests from third parties [RFC6155]."
      I predict that policy URLs will be leaked, intentionally, to those who need them, and that this will lead to security issues down the road. Is there something that we could do about this?
    2. Stephen Farrell: Discuss [2011-12-12]:
      #1 Intro para 2 says that the deref protocol provides a PEP, but just having read it, it doesn't, except for in that very very limited sense of supporting authorization-by-possession. So the claim seems wrong. I'd say just removing the claim is easiest.
      (I guess I agree with Tobias' Apps area review points being a discuss, so... I've broken the overall points down into a number of specific things below, hopefully that'll help get 'em sorted quicker.)
      #2 Why even allow HTTP URIs? Why not insist on HTTPS for this? geopriv-deref does (almost correctly) insist on use of TLS so it seems illogical for this to be more open. In any case, the same choices would be best for both of these specs I think wrt TLS usage.
      #3 For the case where a policy URI is a "shared secret," what TLS server auth settings are required to be used? Would it be good to say the client MUST NOT offer TLS_*_anon_* ciphersuites in the client hello?
      #4 Saying the policy server SHOULD allow all requests (3.1 2nd para) seems unwise. It may be reasonable to allow for the URI-is-secret model, but I don't get why you want to prevent anything more? (That's how I interpret the SHOULD.) Saying (at the end of section 3) that a new policy URI MUST be generated whenever a new location URI set if generated also seems to work against any other (better;-) kind of authorization.
      #5 Assuming URIs remain secret seems problematic. Is there evidence that the confidentiality of these URIs can be maintained really?
      #6 Describing the policy URI as a shared secret doesn't seem to be enough. I think you need to say that it MUST be a practically unguessable shared secret, even if I have seen many such URIs. The DHCP option in 4.2 means that anyone can I guess get the server to emit loads of policy URI values.
      #7 Why is it reasonable to have a default of making location available (to possessor's of the URI)? Couldn't that be dangerous in conjunction with some other defaults (e.g. some other protocol might default to including a location URI in a message), or is there somewhere in geopriv where it says that the overall default is that location information has to be denied by default?
      #8 Why not acually define a good policy URI generation function rather than give all these partial hints? I don't even necessarily mean as a MTI but rather as a good example of how to do it.
      #9 What is the argument that 2^32 unique policy URIs is a big enough number?
      #10 (2^(N/2))/T is meant to restrict an unlimited attacker to one successful guess per T seconds? Is that correct and the intent? Be better to explain your logic there. If that is the intent, I don't see why its considered a good thing. (Be fun to sse if my arithmetic is screwed up there or not;-)
      #11 What are the likely values of T that will be used? It seems odd to only introduce a lifetime value like this at this point. Maybe you mean that T is some value derived from system behaviour rather than a parameter? If the former, then is it reasonable to expect the rate limiting enforcement function to have that number available to it?
    3. Stephen Farrell: Comment [2011-12-12]:
      - Just adding 32 random bits to the mix might not be enough if you have ~ 2^32 clients. Worth noting?
      - 2^(N/2)/T is likely to be error-prone. One more set of parenthesis would be good.
    4. Pete Resnick: Comment [2011-12-13]:
      Please consider the review of Tobias Gondrom <http://www.ietf.org/mail-archive/web/apps-discuss/current/msg03926.html*gt;. I will defer to the expertise of the Security ADs to consider whether the issues he points out are worthy of DISCUSSion, but I have not seen a public reply to his message.
      [Updated to add:] I note from the writeup that there are no implementations of this. I also note that geopriv-policy is given as an example of what might be used as a policy document in addition to the others. Is my suspicion correct that, in fact, down the road geopriv-policy will be the *predominant* use of this URI? If so, is it not worth holding this document until that one is completed? I suspect it will end up a lot shorter if it could talk in terms of an actual GEOPRIV policy document and use the others only as examples. (I see no need to hold a DISCUSS position on this, as I think there is no harm in publishing this first, but I would like to hear from the authors/chair/WG as to what the reasoning was.)
    5. Peter Saint-Andre: Comment [2011-12-13]:
      I concur with the DISCUSS position of Stephen Farrell.
      Why does this specification use the term "Internet host" instead of the term "Target" from RFC 3693? Consistency across this suite of documents would be good.
      It would be helpful to cite RFC 3693 and RFC 5808 in Section 2.
      In Section 4.1, the schema references "urn:ietf:params:xml:ns:geopriv:held:policy" but that namespace is never used in the schema definition.
      In the examples, it would be helpful to point to the specifications that define the various data structures (i.e., the "urn:ietf:params:xml:ns:geopriv:held", "urn:ietf:params:xml:ns:common-policy", and "urn:ietf:params:xml:ns:geolocation-policy" namespaces).
      The second block of XML in Section 5.3 never defines the gp: prefix (i.e., you need to add xmlns:gp="urn:ietf:params:xml:ns:geolocation-policy" to the root <ruleset/> element).
    6. Sean Turner: Comment [2011-12-15]:
      I'm with Stephen and Jari on this one and definitely support Stephen's discuss. This really feels like security through obscurity, but if I let you see mine then you can be me for while.

    Telechat:

  5. Connection Establishment for Media Anchoring (CEMA) for the Message Session Relay Protocol (MSRP) (Proposed Standard)
    draft-ietf-simple-msrp-cema-03
    Token: Gonzalo Camarillo
    Note: Hisham Khartabil (hisham.khartabil@gmail.com) is the document shepherd.
    Discusses/comments (from ballot 4005):
    1. Stephen Farrell: Discuss [2011-12-14]:
      #1 Lawful intercept is not a feature in this context (see rfc 2804) I'd say just delete the phrase and you'll loose nothing.
      As you'll see from the points below I have some issues with how you're using TLS. Could be that some of this is just a lack of context on my part but I'd like to check at least.
      #2 What name is authenticated in "name based authentication"? Would any such name (in a cert issued by a locally trusted CA) do just fine?
      #3 2nd para of 7.2: if an MSRP endpoint can get an "incorrect impression" about TLS in the presence of a middlebox then how does the MSRP endpoint ever benefit from authentication?
      #4 How is the MIKEY reference not normative? 7.2 RECOMMENDS doing either 1) TLS certs with blah (RFC 6042) or 2) MIKEY stuff. The MIKEY RFC (RFC 6043) is informational so that's a downref.
      #5 I don't understand how MIKEY for managing TLS-PSK values is well-defined. The string "TLS" does not occur in RFC 6043. (I'd just drop the MIKEY idea entirely - is anyone really gonna do that?)
      #6 Can you re-assure me that there are in fact implementations of RFC 6072 and RFC 6043 (in the latter case usable for managing TLS-PSK symmetric keys). If so, great, I'd appreciate some pointers to those. If not, then are you really building on fiction? Wouldn't that be a bad plan?
      #7 I don't get the trust model for "fingerprint" based authentication for TLS. Who's including the fingerprint where and using it to verify what self-signed cert?
      #8 How do MSRP endpoints figure out what authentication methods they have in common in a way that's not attackable by an on-path active attacker? What is the list of "mechanisms" that you mean in 7.2 (para starting with "If possible, ...")
      #9 I get the impression that the 2nd last paragraph of 7.2 is what you think people will actually do and that all the rest of that section is window dressing. Am I wrong? If I'm right, then why not just plainly say that and then we can discuss it more easily?
      #10 If I'm wrong about #9: On what basis can an MSRP endpoint pick between the two choices at the end of 7.2? What code do I write?
    2. Stephen Farrell: Comment [2011-12-14]:
    3. Pete Resnick: Comment [2011-12-10]:
      Section 3: "Support of the extension is optional."
      Do you mean "OPTIONAL"?
      "MSRP endpoints that support CEMA are required to use RFC 4975 behavior in cases where they detect that the CEMA extension cannot be enabled."
      Do you mean "REQUIRED"?
      Section 4.1: "In the following cases, where there is a Middlebox in the network, the CEMA extension cannot be used..."
      Do you mean "MUST NOT be used"?
      Section 4.2: "When the offerer receives an SDP answer, if the MSRP media description of the SDP answer does not contain an SDP 'msrp-cema' attribute, the offerer MUST check the criteria below. If either or all of the criteria is met, the offerer MUST fallback to RFC 4975 behavior, by sending a new SDP offer according to the procedures in RFC 4975 and RFC 4976."
      This is mostly editorial, but since it involves 2119 language, I think it's worth fixing: The first MUST is redundant. If the offerer MUST do things based on the criteria, there is no need to say that you MUST check the criteria. (Also, "either" is the wrong word when there are more than two criteria. You meant "any".) Instead maybe:
      "The offerer MUST fallback to RFC 4975 behavior, by sending a new SDP offer according to the procedures in RFC 4975 and RFC 4976, if it receives an SDP answer whose description does not contain an SDP 'msrp-cema' attribute, any of the following criteria are met: [1... 2... 3...] The new offer MUST NOT contain an SDP 'msrp-cema' attribute."
    4. Peter Saint-Andre: Comment [2011-12-07]:
      It seems to me that the security considerations are somewhat underspecified, and I find the concept of a TLS B2BUA unsatisfying, but I will let folks from the security area comment on those aspects of the specification.
    5. Robert Sparks: Discuss [2011-12-13]:
      There are two paragraphs in section 7.2 (the ones starting "When an MSRP endpoint" and "If possible, MSRP endpoints") that need to be scoped to this extension. It might be enough to say CEMA-enabled MSRP endpoint everywhere you currently say MSRP endpoint, but that would likely make the text hard to read.
      There's something wrong with the second paragraph and the list that follows it. It currently says "Check every authentication mechanism at your disposal. If they all fail, then based on local policy, decide whether you want to believe the failure is because there is a benign network that's trying to help you instead of a malicious party trying to hurt you." Is that what the document was actually trying to say? If so, then if you're going to allow an endpoint to make that decision (and I don't think you should since there's no way to tell that all the network elements are actually part of that benign network), why waste the time authenticating in the first place? Unless the paragraph intended something completely different, option 2 in the list should be removed.
    6. Robert Sparks: Comment [2011-12-13]:
      The short title that appears on every page but the first needs to be changed. It's currently MRSP. CEMA or MSRP-CEMA would be better.
      In section 4.2, "either or all of the criteria" is unclear. I suggest "any of the following criteria" instead.
      In 4.2 and 4.3, there are notes about resolving domain names before trying to match against addresses in c or m lines in SDP. They currently say "whether there address". I suggest "whether the address" instead.
      In section 4.4 when you discuss handling multiple records from DNS, it's not clear whether all the resolved addresses must match or only one in the set must match.
    7. Sean Turner: Discuss [2011-12-15]:
      s7.1: I believe the following requires a normative reference to TLS: "For backward compability, a CEMA-enabled MSRP endpoint MUST implement TLS."
      s7.2: What is "a common authentication mechanism" in following:
      "If possible, MSRP endpoints MUST use name-based authentication. If not possible, if the MSRP endpoints support a common authentication mechanism, they MUST use that mechanism. If the MSRP endpoints do not support such common authentication mechanism, they MUST try fingerprint-based authentication, which will succeed if there are no Middleboxes present. If that also fails, the MSRP endpoints MUST either:"
    8. Sean Turner: Comment [2011-12-15]:
      s1: strike lawful intercept (I see Stephen made this a discuss otherwise I would have made it one too)
      s2: Fingerprint Based TLS AUthentication:
      r/self-signed TLS certificate/self-signed certificate
      r/fingerprint/fingerprint (i.e., a hash of the self-signed certificate)
      s2: Name Based TLS Authethication
      r/certificate authority/certification authority
      r/SubjectAltName parameter/SubjectAltName extension
      s3: r/Support of the extension is optional./Support of the extension is OPTIONAL.
      s7.2: certificates are by definition public so I'm a little confused by the following:
      "1. TLS certificates together with support of interacting with a Certificate Management Service [RFC6072], to which it publishes the public version of its own self-signed certificate and from which it fetches on demand the public certificates of other endpoints."
      Maybe:
      "1. TLS certificates together with support of interacting with a Certificate Management Service [RFC6072], to which it publishes its self-signed certificate and from which it fetches on demand the self-signed certificates of other endpoints."
      s7.2: (Stephen caught this too) MIKEY-TICKET is a normative reference.
      s7.2: I share the same concerns Stephen has wrt the fingerprint authentication.
      s7.3: Probably worth a pointer to the SIP issues based on the following:
      "Even with seemingly end-to-end media integrity, at the time of the publication of this document there are other vulnerabilities in MSRP, due to vulnerabilities in the SIP signaling."

    Telechat:

  6. The NewReno Modification to TCP's Fast Recovery Algorithm (Proposed Standard)
    draft-ietf-tcpm-rfc3782-bis-04
    Token: Wesley Eddy
    Note: David Borman (david.borman@windriver.com) is the document shepherd.

    Discusses/comments (from ballot 4013):
    1. David Harrington: Comment [2011-12-13]:
      I read the document. I got a bit lost in the details. The document appears to be well-written.
      in section 2, "This document assumes that the reader is familiar with the terms SENDER MAXIMUM SEGMENT SIZE (SMSS), CONGESTION WINDOW (cwnd), and FLIGHT SIZE (FlightSize) defined in [RFC5681]. FLIGHT SIZE is defined as in [RFC5681] as follows:"
      If you assume the reader is familiar with the FLIGHT SIZE definition, why repeat it here? If you repeat the defintion of flight size here, why not SMSS and CWND as well?
      It would have been good to have a tsvdir review of this document.
    2. Russ Housley: Discuss [2011-12-14]:
      The Gen-ART Review by Ben Campbell on 21-Nov-2011 against -03 of this document raised several concerns. Draft -04 has been posted, but none of the concerns were addressed, nor was Ben told why his concerns were incorrect.
      Please respond to these concerns from Ben's Gen-ART Review:
      -- Appendix A refers the reader to RFC 3782 for additional information. But this draft purports to obsolete that RFC. If there is important information in it that document that is not covered by this draft, then it doesn't really obsolete it. Is there a reason that information was not brought forward into this draft?
      -- There is very little RFC 2119 normative language. On a quick scan, I see one capitalized SHOULD NOT and one MAY. Yet it seems like there are other statements that are just as important for correct behavior as those. For the sake of consistency, it might be easiest to just drop the RFC 2119 language entirely.
    3. Russ Housley: Comment [2011-12-14]:
      Please consider the comments raised in the Gen-ART Review by Ben Campbell on 21-Nov-2011.

    Telechat:

2.1.2 Returning Items

  1. An IPv6 Routing Header for Source Routes with RPL (Proposed Standard)
    draft-ietf-6man-rpl-routing-header-06
    Token: Jari Arkko
    Note: Brian Haberman (brian@innovationslab.net) is the document shepherd.
    Discusses/comments (from ballot 3769):
    1. Ralph Droms: Discuss [2011-11-29]:
      I have two Discuss issue that should be easy to resolve.
      1. I think there is an inadvertent omission of some text. From section 4.2:
      "When forwarding an IPv6 datagram that contains a SRH with a non-zero Segments Left value, if the IPv6 Destination Address is not on-link, a router SHOULD send an ICMP Destination Unreachable (ICMPv6 Type 1) message with ICMPv6 Code set to (TBD by IANA) to the packet's Source Address."
      There should also be text explicitly requiring that the router drops the datagram.
      2. This issue requires a little clarification before I can provide an actionable Discuss issue. Is it possible to deploy RPL in a network in which not all of the nodes in the network participate in RPL? E.g., can there be "leaf" nodes, the equivalent of hosts, that do not participate in RLL and that exchange datagrams with immediate neighbors that are RPL routers? If so, I think there needs to be additional text similar to that in section 5 describing how a RPL router must ensure that it doesn't forward a datagram containing an SRH to a non-RPL leaf node.
    2. Ralph Droms: Comment [2011-11-30]:
      Comment added on 11/30.
      The working group summary is pretty terse. I think it would be helpful to explain that the design and use of the option morphed several times during the working group discussion before it arrived at its current state. Also, the working group summary should refer to the roll (not RPL) working group.
    3. Adrian Farrel: Comment [2011-11-30]:
      I have no objection to the publication of this document, but I have a number of small editorial questions/comments that I hope you will address along the way.
      (8 items)
    4. Stephen Farrell: Comment [2011-12-14]:
      (blank)
    5. Robert Sparks: Comment [2011-11-29]:
      (blank)

    Telechat:

  2. ARP Mediation for IP Interworking of Layer 2 VPN (Proposed Standard)
    draft-ietf-l2vpn-arp-mediation-18
    Token: Stewart Bryant
    Note: Document Shepherd: Nabil Bitar, nabil.n.bitar@verizon.com
    Discusses/comments (from ballot 3912):
    1. Jari Arkko: Discuss [2011-09-22]:
      I am reading the ND modifications and trying very hard to convince myself that they are correct and complete. I'm not 100% sure I've managed to do that.
      I scanned the mailing list for 6man and found no discussion of this draft. Did I miss it? Shouldn't relatively complex surgery on ND require some review from the experts on ND?
      I'm also wondering if the SEND proxy specification from CSI WG would be an applicable recommendation in addition to recommending turning SEND off.
      To be more specific, can you:
      1) perform a 2-week last call in 6MAN for additional review, and
      2) either point to the use of the SEND proxy specification or provide reasons why it cannot be used
    2. Ralph Droms: Comment [2011-09-21]:
      In section 4.3.3, is "the link-layer address of the local AC" really "the link-layer address of the PE interface attached to the local AC"?
    3. Adrian Farrel: Discuss [2011-09-22]:
      I will move to a "Yes" ballot when my Discuss has been resolved.
      Why does this document include a redefinition of the Address List TLV that is already defined in RFC 5036? Although the text says that it is using the RFC 5036 definition, the text also says that the I-D defines the Address List TLV.
      Shouldn't you simply refer to 5036 and say how the fields are set for your specific use?
      Similarly the redefinition of the Notification message.
      To be clear, the main reason for objecting to the redefinition is that it opens the door to discrepencies, and makes it hard to handle future extensions. (Coders should be familiar with the practice of only defining data structures in one place :-)
      Please add some text to clarify whether the Stack Capability field in the Stack capability Interface Parameter sub-TLV is an integer or a bit-field.
      The IANA section makes it look like a bit field (which is what I would expect) but the text in the main body says... "Stack Capability = 0x0001 to indicate IPv6 stack capability" ...which makes it look like an integer
      Additionally, the text goes on to imply that the interpretation of the field is context-specific...
      "The value of Stack Capability is dependent on the PW type context. For IP Layer2 Transport type, a setting of 0x0001 indicates IPv6 stack capability."
      ...if this is the case, presumably, 0x0001 could mean something else in other circumstances. How is this tracked in the IANA registry?
    4. Adrian Farrel: Comment [2011-09-22]:
      Should the figure on page 5 include the label "AC3"?
      I agree with the other ADs who are concerned about the use or non-use of RFC 2119 language. Hopefully, this will be easy for you to clean up and will not be construed as changing the technical content of the document.
      "The "IP Layer 2 interworking circuit" pseudowire is also commonly referred to as "IP pseudowire". "
      Can you insert a reference for "IP pseudowire"?
    5. Stephen Farrell: Comment [2011-09-16]:
      - 8.1 says that you "can" secure the PE-PE control plane "using MD5 authentication." Is that (still) the best that can be done? Doesn't it need a reference? Why can't something better be used, e.g. IPsec? Why no 2119 language? (This isn't a discuss because I hope that all that's in some other RFC.)
      - 8.1 says that this protocol is incompatible with SEND. I guess that's inevitable, but do you need to say more about the trade-offs concerned, e.g. would it ever be likely that a CE that depends on SEND is deployed and later on a PE doing this protocol is installed breaking the CE or changing its security properties in a bad way? (Just wondering.)
      - Frame Relay (FR) is expanded only on its 2nd use. 1st use is in 2nd para of section 1.
    6. David Harrington: Discuss [2011-12-14]:
      1) in section 2, it says IPv4 L2 interworking MUST be supported, but it is only a SHOULD for IPv6. Why is IPv6 mediation not a MUST for PEs?
      (please note that draft-ietf-intarea-ipv6-required-02 is in IESG Eval for Proposed Standard. It hans't been approved yet, but probably will soon.)
      2) in 3, "In this case, all data link headers are removed to expose the IP packet at the ingress." should this be MUST remove?
      3) in 2, "Intercept Neighbor Discovery and Inverse Neighbor Discovery packets received over the pseudowire from the remote PE, possibly modifying them (if required for the type of outgoing AC) before forwarding to the local CE,"
      Can the RFC2119 language make "possibly if required" less ambiguous? Does possibly mean "MUST if REQUIRED" or "SHOULD if REQUIRED" or "MAY if REQUIRED"? and please make sure this section is consistent with section 3, "In the case of an IPv6 L2 Interworking Circuit, the egress PE MAY modify the contents of Neighbor Discovery or Inverse Neighbor Discovery packets ..."
    7. Russ Housley: Comment [2011-09-21]:
      The Gen-ART Review by Peter McCann on 20-Sep-2011 raised a minor issue and two editorial suggestions:
      Section 5.2 says: "Since this notification does not refer to any particular message the Message ID and Message Type fields are set to 0." There does not appear to be a Message Type field in the PDU.
      Section 5: suggest replacing the idiom "chicken and egg situation" with "possible deadlock situation."
      Section 5.2: "Section 6. below." should be "Section 6 below."
    8. Pete Resnick: Comment [2011-09-21]:
      1. This entire document needs a good "MUST/SHOULD/MAY vs. must/should/may" scrubbing. Just to cite two examples:
      4.2.2: "When the PE learns the IP address of the remote CE, it should generate an Inverse ARP request."
      It "should"? Or it "SHOULD"? Or it "will"?
      4.3.2: "If a Router Discovery message contains a link layer address, then the PE MAY also use this message to discover the link layer address and IPv6 interface address."
      That MAY doesn't sound like a protocol option.
      2. Section 2: "PEs MUST support ARP mediation for IPv4 L2 Interworking circuits. PEs SHOULD support ARP mediation for IPv6 L2 interworking circuits."
      I assume this means "PEs that support ARP mediation MUST support it for IPv4 and SHOULD for IPv6". The way it is now, it sounds like ALL PEs must support this, which can't be right. That said, I see no reason for this paragraph. Mediation should be supported on both v4 and v6 circuits. I say drop the paragraph.
      3. For the record, and not something the authors need to address: I understand that the IETF doing sub-IP protocols is a ship that has sailed long before I got on the IESG. However, the mind boggles that we are deploying this particular protocol: Why can't we simply *route*?!?!? This protocol is standing on its head to allow layer 2 bridging of IP across disparate links instead of just having a routed VPN. This is goofy, it is a complete layer violation, and I don't think we should be standardizing this nonsense.
      There, I feel marginally better. :-/
    9. Peter Saint-Andre: Comment [2011-09-21]:
      This document appears to be predicated on "know[ing] that only IP traffic will be carried". How is this determined?
    10. Robert Sparks: Comment [2011-09-21]:
      Section 7.2 invokes an IANA well known policy of "IETF Consensus", referencing RFC5226, but that RFC has renamed that particular policy to "IETF Review".
    11. Sean Turner: Comment [2011-09-22]:
      I have the same question Stephen did about MD5.

    Telechat:

2.2 Individual Submissions

2.2.1 New Items

  1. Reserved IPv6 Interface Identifier for Proxy Mobile IPv6 (Proposed Standard)
    draft-gundavelli-v6ops-pmipv6-address-reservations-05
    Token: Jari Arkko
    Discusses/comments (from ballot 3904):
    1. Jari Arkko: Comment [2011-10-20]:
      (blank)
    2. Ralph Droms: Comment [2011-09-07]:
      There seem to be a couple of syntax issues in this text:
      OLD: "The base Proxy Mobile IPv6 [RFC5213] all though required the use of a fixed link-local and a fixed layer-layer address,"
      NEW: "Although the base Proxy Mobile IPv6 [RFC5213] requires the use of a fixed link-local and a fixed link-layer address,"
    3. Wesley Eddy: Comment [2011-08-30]:
      I think this is a useful document. It seems like it should have "Updates: RFC 5213" though?
    4. Adrian Farrel: Comment [2011-09-06]:
      Section 1: "To address this problem, this specification makes the following two reservations. The mobility elements in the Proxy Mobile IPv6 domain MAY choose to use these fixed addresses."
      Stumbled over this because it looks like the second sentence is a reservation (i.e. a modification to the base spec), but there is only one reservation listed.
    5. Pete Resnick: Comment [2011-09-05]:
      Strike section 2.1. 2119 is not used in this document.

    Telechat:

2.2.2 Returning Items

  1. IANA Reserved IPv4 Prefix for Shared CGN Space (BCP)
    draft-weil-shared-transition-space-request-10
    Token: Ron Bonica
    Discusses/comments (from ballot 3933):
    1. Jari Arkko: Comment [2011-12-01]:
      FWIW, the issue that I had with the previous incarnation of this document has been resolved. Thanks for working through the measurements and evidence about risks, and documenting them.
      However, my fellow AD colleagues have raised other issues (including status of IETF consensus for this document). I defer to them on those issues.
    2. Ron Bonica: Discuss [2011-11-29]:
      I will change this ballot to "YES" when a /10 has been allocated for this space.
    3. Stewart Bryant: Discuss [2011-11-29]:
      I understand the commercial imperatives that the ISPs face, and appreciate this is a dilemma.
      However, the authors have not so far generated an adequate degree of consensus (as evidenced by discussions on the IETF list) that the deployment of this technology "makes the Internet work better". Indeed section 5 indicates that the deployment of this technology makes the Internet worse by reducing it to a network that only supports a limited range of services (Web, Mail and IM) sanctioned by the ISP. This seems contra to the mission of the IETF.
      If this were a clearly defined limited application network, a case could be developed for accepting restrictions, but the application described here is connectivity to the Internet and hence access to new innovative services.
      The authors need to gain consensus in the IETF, that there is no other solution to the problem in hand, and hence that the significant restriction on the type of user application supported is justified.
    4. Ralph Droms: Discuss [2011-11-30]:
      I am posting a Discuss position for this document because the IESG should discuss some fundamental issues of how we should make a decision about publication of this document.
      I also have concerns about whether the IESG is the appropriate body to approve this request. I intend to post an Abstain position after my questions are answered and I clear my Discuss.
      The conversation about this document and any attempt to determine consensus is difficult because the issues are technical, economic, political and psychological. We (the IESG) are well-equipped and responsible for decisions about technical issues, but less so for the other issues.
      I've been reading most of the e-mail in the consensus call on ietf@ietf.org. Here are some of the questions I think I've seen discussed:
      - Does the assignment of the requested /10 enable or hinder the deployment of IPv6?
      - Is CGN a viable service model for IPv4?
      - Is the reserved /10 required for the deployment of CGN?
      - Can the deployment of CGN be prevented by not assigning Shared CGN address space?
      - What is the effect of burning 4 million IPv4 addresses on the exhaustion of IPv4?
      - Can alternative /10s be used such as 10.64.0.0/10 or 240.0.0.0/10?
      - How many ISPs really want this assignment and how many don't care because they don't need it?
      Most of these questions are, in fact, not technical questions and I don't think the IESG can answer them. The document itself addresses only a few issues, giving one reason not to use each of the alternatives:
      o legitimately assigned globally unique address space
      o usurped globally unique address space (i.e., squat space)
      o [RFC1918] space
      In particular, the reason for not using RFC 1918 space is simply asserted with no support facts.
      If the IESG is to make a decision, I would like to walk through the following questions:
      - Is the IESG the appropriate body to make the decision? If no, where should the decision be made, perhaps with technical advice from the IETF?
      - Should the IESG identify any specific /10 for use as Shared CGN Space? If no, do not approve the document.
      - Does this document describe the usage scenarios, constraints and caveats sufficiently well to allow the use of a /10 as Shared CGN Space? If no, ask for a revision.
      - Should the IESG approve a request to IANA for a /10 as described in the document? If yes, publish the document.
      - Should the IESG request that IANA identify some other /10 (or similar address block), such as 172.16.0.0/12, 10.64.0.0/10 or 240.0.0.0/10 for use as Shared CGN Space?
    5. Wesley Eddy: Comment [2011-11-30]:
      I agree with the comments and discuss positions from others that say there is not IETF consensus on this document.
    6. Adrian Farrel: Comment [2011-11-30]:
      I concur with Stewart that there does not appear to be IETF consensus around this I-D.
      I am concerned that the alternative to this has been presented as "if you don't allocate the address space, the ISPs will just squat on another space." However, this also seems to be less worser than any other proposal on the table.
    7. Stephen Farrell: Comment [2011-12-08]:
      Based on more and more and more and more discussion I'm reluctantly ok with this.
      I think additionally allocating part of 240/4 would be a fine thing to do at the same time within the same document. I would not be that keen on punting on the 240/4 part allocation until later since that would engender most of the same discussion.
    8. David Harrington: Discuss [2011-12-13]:
      I believe there is not IETF Consensus for approving a /10 for this purpose, and, as a result, there is not IETF consensus to approve this document.
      This document describes a number of problems that occur with CGN, even with this shared /10, so CGN does not make the Internet run better. I think there is IETF consensus that widespread deployment of CGN could be damaging to the Internet. I believe approving Shared CGN space to make CGN deployment easier is counter to the IETF mission of making the Internet run better, and approving allocation of this /10 does not represent IETF consensus.
    9. Pete Resnick: Discuss [2011-12-01]:
      Calling out one piece of Ralph's DISCUSS directly: I agree with Ralph and Stephen that the question of whether there is another existing block of addresses that will cause less potential application damage and is still usable by CGNs (e.g., 10.64/16, 172.16/12, 240/10) has not yet been sufficiently answered. The proponents have claimed that there is full *use* of the 1918 space, but not whether there is full use *by* devices that can't deal with 1918 address space on their "external" interfaces. Until that question is answered, we can't tell if the risk of application damage really is outweighed by the risk to deployment.
    10. Pete Resnick: Comment [2011-12-01]:
      I agree with Ralph's DISCUSS: We need to first come up with a list of criteria by which consensus can be judged. While I agree with most folks that there is *disagreement* on the list as to whether this allocation should be made, I think some of the issues on which there is disagreement are not legitimate criteria for the consensus call. (For example, "Is CGN a viable service model for IPv4?" is *not* something that we should be using as a criteria for consensus.) Before we come to a conclusion on consensus, we need to lay out the legitimate issues being discussed and whether there is consensus on each of them.
    11. Dan Romascanu: Discuss [2011-12-01]:
      Ralph sumarized well and in details the reasons for which the IESG cannot approve this document under its current form and at this point in time. I will probably change my DISCUSS into an Abstain after the telechat, unless we come with a different plan of action.
    12. Peter Saint-Andre: Comment [2011-12-08]:
      Based on list discussion, I have come to the conclusion that this is the least worst workaround (not "solution") available to us at this time.
    13. Robert Sparks: Discuss [2011-12-01]:
      While I personally agree with the position that approving this allocation is the least bad of the available choices, I don't believe IETF consensus for approving this document as it is currently written exists.
    14. Robert Sparks: Comment [2011-12-01]:
      I encourage pursuing Ralph's questions and carefully separating the question of allocating the address space and what effect CGNs may have on the Internet.
    15. Sean Turner: Comment [2011-12-01]:
      I agree with Ralph.

    Telechat:

3. Document Actions

3.1 WG Submissions

3.1.1 New Items

  1. A Framework for the Control of Wavelength Switched Optical Networks (WSON) with Impairments (Informational)
    draft-ietf-ccamp-wson-impairments-08
    Token: Adrian Farrel
    Note: Deborah Brungard (dbrungard@att.com) is the Document Shepherd.
    Discusses/comments (from ballot 3961):
    1. Ron Bonica: Comment [2011-12-13]:
      == Missing Reference: 'Eppstein' is mentioned on line 1020, but not defined
      == Missing Reference: 'RFC5920' is mentioned on line 1138, but not defined
    2. Stephen Farrell: Comment [2011-11-26]:
      (blank)
    3. Russ Housley: Comment [2011-12-14]:
      The Gen-ART Review by Wassim Haddad on 13-Dec-2011 raised one editorial comment. Please consider it:
      - In Security considerations section: s/maybe/may be/
    4. Pete Resnick: Comment [2011-12-13]:
      I am left wondering why this document is being published in the IETF instead of elsewhere and then later referred to by a GMPLS document that will use this terminology and framework, but I can say that I do not have a clue about the technology and am therefore deferring to others to review the content of this document.
    5. Dan Romascanu: Comment [2011-11-01]:
      Bert Wijnen made the following comment (that I support) in his OPS-DIR review:
      As the document writeup states: "This document is an informational framework with nothing to implement. There are a number of drafts being progressed that address various aspects of the framework."
      So it would be those documents being progressed that would have to include any discussion about operational or manageability aspects of the various solutions.
      At the other hand, it might have been useful if this document would have touched upon some operational/manageability aspects for each of the possible solutions. It seems clear that there are different characteristics depending on which solution is chosen. Specifically the talk about "black links" makes me worried that solutions can become complex and less interoperable.
    6. Sean Turner: Comment [2011-12-13]:
      s6/s8: Need add a reference to [RFC5920].

    Telechat:

  2. Problem Statement of Peer-to-Peer Streaming Protocol (PPSP) (Informational)
    draft-ietf-ppsp-problem-statement-07
    Token: Wesley Eddy
    Note: Martin Stiemerling (martin.stiemerling@neclab.eu) is the document shepherd.
    Discusses/comments (from ballot 3979):
    1. Jari Arkko: Discuss [2011-12-15]:
      I do, of course, support the development of a P2P streaming protocol, and I think it will be good for the industry. It is good to write a document that provides some justification and background for this.
      However, I do agree with others who have commented that the document overdoes this a little bit. A shorter and more matter-of-fact style would have worked better on me.
      But that is not my Discuss comment, I also have a more specific technical concern. Section 3.1 makes it sound like to deploy P2P caches an ISP needs to implement DPI-based detection of P2P content. I think that is first of all wrong, as adding the ISP as a participant in the particular trackers and P2P networks offers a much cleaner way to do this. Secondly, I do not think the IETF should condone or recommend DPI-based hidden caching.
      This does not change the fact that I agree with the general point of Section 3.1 that a standardized method will be easier to implement, even when you do the implementation in the correct way.
      I suggest deleting some of the text from Section 3.1. that deals with the specifics of how the ISP deals with participation in a P2P network; those details are unnecessary for the general point to be made.
    2. Stewart Bryant: Discuss [2011-12-12]:
      There is a fine line between providing evidence for a case to design something and delivering a commercial message. Unfortunately, even though the author does not appear to work for the companies mentioned the introduction sounds like a commercial. Additionally later in the document there is reference to at least one other company.
      Please will the author look at each mention of a company name and re-write the text to provide the evidence in a more objective, vendor neutral, style.
    3. Adrian Farrel: Discuss [2011-12-13]:
      As it stands, I'm affraid I don't see much value in this document. Although it is probably harmless and the usecases may provide valuable background, a lot of the document is a discussion around the topic and does not give the WG any guidance or instructions.
      I think most of the "justification" in the Introduction is not really needed. Since the WG has been chartered, it is not necessary to go into great detail on your motivation. You could lift a few lines from the WG charter, and then use the paragraphs that say what this document does.
      Similarly, section 3 provides motivation for a standard PPSP, but the existence of the WG is plenty good enough orivation for the work. What seems to be missng, however, is the problem statement that says what the PPSP actually has to do. In other words, I find the document strangely without guidance to the developers of a standard PPSP.
      Fixing this might be particularly hard because there is no bug fix and no easy textual addition. Maybe I should phrase the question as "why does the WG see this document as a valuable addition to the canon?"
    4. Adrian Farrel: Comment [2011-12-13]:
      I like that "chunk" is a unit of "block" with sub-unit "piece". What is "block"? :-)
      The definition of CDN in section 2 actually only provides a definition of "CDN node".
      "key signaling protocol" may be unfortunate term because it is used in other context to indicate a protocol that is used to signal "keys"
    5. Stephen Farrell: Discuss [2011-12-14]:
      (Discuss discuss, for the IESG really I guess)
      How does this all fit with decade and cdni? Are we heading towards a good or bad outcome with all those? An example of a bad outcome would be 3 ways to do one thing that are incompatible but the same except for gratuitous differences. Maybe I'm just missing some context but something seems wrong somewhere...
      (And one for the authors/chairs...)
      - I don't see what PPSP WG document will include "considerations on threats and mitigations when combining both protocols in an application." That's the kind of thing that gets forgotten and where protocol specification authors will say "that's not my problem."
      What's the plan for addressing that in the WG?
    6. Stephen Farrell: Comment [2011-12-14]:
      - Section 4 says that you can have pull, push or a hybrid but does say if the PPSP wg is going to work on all of those or some of those. (Its sort of implied that all will be done via different "modes" but that's not clearly stated.) Since it'd be better to only have one "mode," I think the document should justify choosing to do all "modes." (If that's really what the PPSP WG are planning. If not then the document should say what the WG is actually planning.)
      - Section 5 really needs to say what sections 5.x are. They could be use-cases the WG is going to tackle, or maybe the WG will decide later, or whatever is the case. Without that, its hard to know why sections 5.x are present.
      - 5.1: "easily expand the broadcasting scale" just seems wrong. Is that sales-pitch (in which case delete it) or do you mean something else?
      - Section 6 should mention that a malicious (or careless) peer/tracker can leak private information about other peers or trackers.
    7. David Harrington: Discuss [2011-12-14]:
      1) in section 4, there is a discussion of pull-based versus push-based. The discussion talks about the benefits of pull-based (but not the drawbacks) and the fact that most systems use this approach. Then the push-based approach, which few deployed systems use, is discussed including the drawbacks but not much about the benefits. Then the conclusion is that a hybrid system woudl be best, with little justification for why hybrid is more practical, and no discussion of whether anybody actually does this now.
      2) This document is supposed to be a problem statement, but throughout it the design of the proposed PPSP protocol is thrown in. This document should focus on identifying what the problems are that need to be solved. Basically, this should discuss what problems the tracker and peer protocols each must address. This document seems to lump the tracker and peer protocols together as the PPSP protocol, and doesn't differentiate or clearly describe the problems that need to be solved by each protocol.
      I recommend dropping the notion of a PPSP protocol suite, which seems to encourage marketing of PPSP, and blurring of the distinction between the two protocols. This document should focus on describing the problems to be addressed by each of the two protocols:
      "The tracker protocol handles the initial and periodic exchange of meta information between trackers and peers, such as peer lists and content information."
      - what are the problems that a tracker protocol addresses, and what problems must be overcome in its design?
      "The peer protocol controls the advertising and exchange of media data availability between the peers."
      - what are the problems that the peer protocol addresses, and what problems must be overcome in tis design?
      in 5.3, there is an incomplete sentence.
      in 5.3, "a mobile peer within a high-load base station is unlikely to be selected, which may lead to higher load on the base station."
      is unclear. Does this mean "a mobile peer within a high-load base station is unlikely to be selected, because selecting the mobile peer might lead to higher load on the base station."?
      Discussion of the PPSP working group should be removed form the document. The goals and deliverables of the WG are documented in the charter, which will have a similar lifetime as the WG. This document published as an RFC will exist long after the WG has been closed.
    8. Russ Housley: Comment [2011-12-12]:
      Please consider the comments provided in the Gen-ART Review by Francis Dupont on 24-Nov-2011.
    9. Dan Romascanu: Comment [2011-12-15]:
      I find the document useful in intent but problematic in the way it is written, and I beleive that some of the sections need serious editing before publication. As the critical issues are covered in DISCUSSes of other ADs I will enter them as COMMENT:
      1. Section 1 needs to be shortened and all 'commercial' content needs to be dropped. The main functions should be described avoiding the mentioning of the vendors names.
      2. The requirements from the tracker and peer protocols need to be sumarized and listed in one place. I found the figures in section 5 quite useful to understand the functions, but it took time and effort to go through them as they are disparated in the descriptions of the use cases
      3. Avoid text (like in the Abstract) that may be interpreted as the protocol proposal is included in this document
    10. Peter Saint-Andre: Comment [2011-12-05]:
      The first three paragraphs of the Introduction are mostly marketing and deserve to be deleted.
      "In this document we propose an open P2P Streaming Protocol..." I think you mean "propose the development of" because this document does not define such a protocol.
      Section 3.3, paragraph 1: these numbers will become stale quickly. I suggest removing this paragraph.
    11. Robert Sparks: Comment [2011-12-13]:
      It's not obvious how this document is going to help the working group with it's protocol work, or help document the work once it's complete. Is the set of use cases intended to be a set of motivating examples, or does it exhaustively cover every scenario the protocol is expected to handle? Please consider clarifying those points.

    Telechat:

  3. Happy Eyeballs: Success with Dual-Stack Hosts (Informational)
    draft-ietf-v6ops-happy-eyeballs-06
    Token: Ron Bonica
    Note: Fred Baker (fred.baker@cisco.com) is the document shepherd.
    Discusses/comments (from ballot 3985):
    1. Stewart Bryant: Comment [2011-11-28]:
      Wes raises an interesting point, the draft needs to discuss connectionless transport protocols.
    2. Wesley Eddy: Comment [2011-12-14]:
      (blank)
    3. Adrian Farrel: Comment [2011-12-11]:
      I understand why improving IPv6 experience in dual stack deployments is valuable to the IETF in promoting migration to IPv6. For that reason, publication of this document may be beneficial and encourage implementations to include more flexible selection algorithms such as that described in this document. However, I don't see anything in this document that impacts interworking, so I don't see why it is Standards Track.
    4. Stephen Farrell: Comment [2011-12-09]:
      (blank)
    5. Stephen Farrell: Comment [2011-12-09]:
      I've cleared
    6. Pete Resnick: Comment [2011-12-11]:
      I really think this document should have had a co-author in the apps area. It is written exceedingly "thinly" and doesn't really understand some of the application implementation issues. That said, I still think it is valuable and worth publishing (and hopefully updating in the future). Though it is a bit this for the standards track as it is now, I see the potential to fill this in over time with more proscriptive information, and therefore I don't object to go it going on the standards track now in anticipation of that. Some issues to consider for this go-round:
      3.1 - This has nothing to do with URIs. It is about hostnames. Hostnames used that don't appear in URIs have exactly the same issues.
      4. - Though using SYN and ACK in the diagram is fine, I recommend using words like "connection attempt" in the descriptive text. SYN and ACK are probably not as familiar to application layer folks, and since this is aimed at them, it is likely better to use the application layer terminology. Furthermore, there is a performance/resource impact to making a "connection attempt" that an apps person will understand that they might not if it is understood as only an additional packet.
      I agree with Stephen's concerns regarding "MUST cache". There are valid reasons to try v6 later even if v4 succeeds first, but those reasons must be carefully considered and understood. That sounds like a SHOULD.
      4.1 - The first few paragraphs strike me as introductory material, not part of the alogirthm requirements.
      4.2. - "SHOULD do so every 10 minutes" I think instead you mean "SHOULD do so no more frequently than every 10 minutes". It's perfectly fine to do so every 20 minutes, or once a day.
      4.3. - DNA does not describe how applications (which are the ones who are going to implement Happy Eyeballs) are to be notified of these changes. Though I agree that a Happy Eyeballs app should be able to ask its host to do a DNA for it (or more to the point, get notifications from the host), that's an additional requirement on these apps and should be noted.
    7. Peter Saint-Andre: Discuss [2011-12-08]:
      The Apps Directorate review by Murray Kucherawy on 2011-11-26 raised two major technical issues and eight minor technical issues. These issues merit a response.
    8. Peter Saint-Andre: Comment [2011-12-08]:
      Much as I love XMPP, I would change "xmpp clients" to "IM clients".
    9. Sean Turner: Comment [2011-12-14]:
      Please consider the editorial comments suggested by Sandy in here secdir review

    Telechat:

3.1.2 Returning Items

  1. (none)

3.2 Individual Submissions Via AD

3.2.1 New Items

  1. Transmission of Syslog Messages over TCP (Informational)
    draft-gerhards-syslog-plain-tcp-12
    Token: Dan Romascanu
    Discusses/comments (from ballot 3840):
    1. Adrian Farrel: Comment [2011-12-11]:
      It would be good if the Introduction included a brief paragraph on the purpose/content of this document. The first paragraph of Section 4 contains roughly the necessary material.
      I am uncomfortable (but not quite to the point of a Discuss) by the way that this I-D flies in the face of IETF consensus to recommend the use of TLS. I believe this could be resolved by a slightly stronger statement on the intent of the document to facilitate interoperability with legacy deployments whild continuing to recommend the use of TLS. I.e. "this document does not recommend that new implementations or deployments use syslog over TCP except for the explicit purpose of interoperating with existing deployments."
      I am surprised that section 5 does not mention TCP/AO.
    2. Stephen Farrell: Comment [2011-12-14]:
      - I agree with Dave's discuss points 1,2 and 4 and sympathise with his point 3.
      - Be nice to add the hex values that go with %d32 and %d126 just to be super-clear
      - 3.1 mentions "relays" but those weren't mentioned in the intro - be nice to say what those are in section 1.
      - What does "not available" mean at the end of section 5? I think it would be better to say "This protocol SHOULD NOT be used unless syslog/tls [RFC5425] has been tried and failed, e.g. because there is no listener on port 6514."
      - I think you could note that falling back to this if syslog/tls fails could in principle indicate that an attack is happening. If there's a sensible action to take there (e.g. some local logging of the failure of the TLS handshake or whatever in addition to remote logging using this) that'd maybe be worth saying.
    3. David Harrington: Discuss [2011-12-13]:
      As co-chair of syslog WG, I have worked witrh Rainer and Chris closely, and understand that they feel this is valuiable documentation for the community. I disagree for a number of reasons.
      1. I think the applicability statement is not consistent with IETF consensus: "It is hoped that this description, along with the assignment of a standardized port for this protocol, will promote future interoperability."
      IETF consensus is to use strong security [RFC3365 - BCP61] to provide secure interoperability. RFC5424 and RFC5425 have IETF consensus as the right way to achieve syslog interoperability, and to do so securely. Based on BCP61, RFC5424 and RFC5425 provide mandatory-to-implement security features, which may be configured by operators to provide no security if operators so choose (RFC5425, section 5). I do not believe this document will result in future interoperability for syslog, and sends the wrong message to the community about how to achieve interoperability. I do not believe it is in the IETF interest to assign a standard port number for syslog/tcp.
      2. I believe this document, if published, should be published as Historic (or Obsoleted by RFCs 5424 and 5425).
      I believe this designation is important based on experience with RFC3164, which allegedly documented BSD Syslog, but actually ended up being a survey of existing syslog/UDP implementations that showed how on-the-wire formats of the many existing implementations had little in common. Most only had the first byte in common. Many vendors claimed "compliance" to RFC3164. I believe this document needs to have it very clearly spelled out that this is only a document of past practices, is NOT an IETF standard, and should NOT be implemented in new implementations.
      RFC3164 (legacy syslog/udp) was obsoleted by RFC5424. This legacy syslog/tcp document should be handled the same way.
      3. Personally, I don't see a lot of value to this document. Similar to existing implementations of syslog that run over udp, existing implementations of syslog that run over tcp are not very consistent.
      This document does not contain enough detail for syslog receivers/applications to process incoming legacy messages; application implementers would need to do additional research into the formats used by specific implementations. Therefore, this document does not serve to significantly improve interoperability between senders and receivers. Cross-vendor interoperability could be improved by standardizing a port#, and recommending consistent implementation choices, such as message layout, support for octet-counting versus framing in the message format, internationalized character sets, and transport session initiation and closure.
      The IETF has already standardized support for a message layout, and internationalized character sets in RFC5424. The IETF has already standardized a transport for syslog messages in RFC5425, including session initiation and closure, a standard port#, as well as strong security as called for by BCP61. I have concerns that publishing this as an RFC sends the wrong message to the community, and am especially concerned that vendors wil use this to claim "compliance" to an IETF RFC, just as they did with RFC3164. This could slow vendors moving to support interoperability by using the IETF standards defined in RFC5424 and RFC 5425.
      4. Despite my belief that publishing this document will not make the Internet run better, I could accept publication of this document with a Historic or Obsolete label and a big IESG Note that says
      "The IESG does NOT RECOMMEND implementing or deploying syslog over plain tcp, which is documented in this document, because it lacks the ability to enable strong security [BCP61]. syslog/tls [RFC5425] is RECOMMENDED for implementation so that security features are available to operators who want to deploy secure syslog, and those security features can be turned off for those who do not want them."
    4. Pete Resnick: Comment [2011-12-13]:
      I must agree with Robert's comment that the port allocation seems inappropriate. However, it concerns me that the port that is chosen some of the time is the rsh port. If there is an unregistered port that is widely used for this, it should be registered.
      I agree with Adrian's comment that some of the contents of section 4 would be terribly helpful in the intro.
      I think Peter's comment regarding character terminology is important, and I'm happy to see you're addressing it.
      I am ambivalent as to whether the document should be Informational or Historic. I lean slightly toward Informational since it is describing widespread current practice.
      [Updated to add:]
      Please re-use ABNF constructs defined in RFC 5234 instead of redefining them here:
      3.4.1 - DIGIT and SP are already defined in 5234.
      3.4.2 - LF is already in 5234.
    5. Peter Saint-Andre: Comment [2011-12-08]:
      According to BCP 166 (RFC 6365): "The terms "charset", or "character encoding scheme" and "coded character set", are strongly preferred over the term "character set" because "character set" has other definitions in other contexts, particularly outside the IETF."
      Please consider changing the term used in Section 3.1 of this I-D to match BCP 166.
    6. Robert Sparks: Discuss [2011-12-13]:
      Capturing a description of what's observable in the wild is a very good thing - thank you for putting this document together. If that's all this document is trying to do, why isn't it Historic, and why doesn't it register the port(s) that existing implementations are actually using?
      A new port for something that's not a standard (and is not already the de facto port) doesn't seem like the right thing to do.
    7. Robert Sparks: Comment [2011-12-13]:
      Most of the document is written with a tone of "here's what we see deployed already", which is good. In a few places it drifts into a tone that would be more appropriate for "and we want people to make more things that do this". Section 3.2, in particular, reads more like a protocol definition than a description of already existing behavior. Section 3.4 uses the phrase "usually preferred". Something like "has caused fewer problems" would be more descriptive (if it's accurate).
    8. Sean Turner: Comment [2011-12-14]:
      I tend to agree with Dave here.

    Telechat:

  2. Recommendations for the Remediation of Bots in ISP Networks (Informational)
    draft-oreirdan-mody-bot-remediation-18
    Token: Stephen Farrell
    Discusses/comments (from ballot 3939):
    1. Jari Arkko: Comment [2011-12-15]:
      Thanks for writing this.
    2. Ron Bonica: Comment [2011-12-14]:
      Minor comments:
      Section 1.3 - Do we really need to define the word host
      Section 1.5 - When IPv6 takes off, you will see fast-flux using AAAA records
    3. Stewart Bryant: Comment [2011-11-28]:
      There is the outstanding issue of verifying that the IPR issues noted by the Shepherd have been fully resolved. I am sure that Stephen will verify the resolution before issuing a publication request, and thus am highlighting this issue as a comment.
      "An ISP may use Netflow [RFC3954]"
      I would think that the the standards based solution IPFIX [RFC5101] would be a better reference.
    4. Wesley Eddy: Comment [2011-11-29]:
      This is a good document. I am not at all an expert in this area, but my only comment is that it seems like there may be some liability to the ISP in attempting to detect bot infections because they may then need to bear the burden to report criminal activity that they witness. I'm sure commercial ISPs have considered this in their policies, but I didn't notice it clearly mentioned in the document.
    5. Adrian Farrel: Comment [2011-12-12]:
      Thanks for a very readable document with a lot of valuable information. I have a few small conversation topics that I would appreciate you thinking about and addressing if you can see a way forward.
      I am surprised by the statement in the Abtract that a user with an infected computer is exposed to the risk of phishing. The second statement that their computer might be used as an inadvertent participant in a phishing network sounds more reasonable.
      I wonder whether Section 5 needs to consider the risks of notifications after false positives, and the problems caused by false notifications as a form of attack.
      Section 7 upset me a little. Recognising the need of ISPs to protect their businesses, I also see the need to continue to provide service to vulnerable people who cannot be expected to protect their computers.
      In view of this, you might discuss the service providers' duty to ensure that hosts connected to their network cannot become infected with bots through data transfered across the service providers' networks. Or you might just drop the text about account termination.
    6. Pete Resnick: Comment [2011-12-13]:
      1.1 - I have never heard of "benign bots" before. Is this an invention of the authors or is it used in some circles? I would prefer if the document referred to only the malicious applications as "bots" and referred to the benign applications as "background applications" or "daemons" or "background processes". I think it is still important to point out that such applications should not be monitored for or prevented from functioning.
      1.2 - "Bot Networks or Botnets" is better defined as "a group of bots that are remotely controlled by a single party". The first sentence of 1.2 is circular.
      I know what all of those malicious activities are, but it might be useful to define some of them.
      "Infection vectors" is undefined. So are a bunch of the terms in that paragraph.
      Much of this section assumes a familiarity by the reader. If the reader was this familiar with the material, this section wouldn't be necessary. Similarly with 1.4.
      1.5 - The information in the two paragraphs is reversed, burying the important point: Compromised hosts are used as proxies to web servers in order to hide the IP address of the server itself. This is *accomplished* by DNS Fast Fluxing.
      10. - Some of the activities outlined in section 3 should be called out specifically with regard to privacy considerations.
      A reference to RFC 4948 seems pretty essential. I'm surprised not to see some of the information that appears in that document in this one.
    7. Dan Romascanu: Comment [2011-12-15]:
      Good document. All my comments are related to Section 5:
      1. "It should be possible for the end user to indicate the preferred means of notification on an opt-in basis for that notification method. It is recommended that the end user should not be allowed to totally opt out of notification entirely.
      It looks like either 'totally' or 'entirely' is redundant
      2. I would expect notifications by management protocols like SNMP and NETCONF be also described in this section
      3. The danger of DoS attacks by flasely reporting of bots via notifications shoulsd also be mentioned as a major security concern
    8. Peter Saint-Andre: Comment [2011-11-29]:
      Overall this is a helpful document. I have a few comments and suggestions.
      In Section 1.2:
      OLD: "The detection and destruction of bots is an ongoing issue and also a constant battle between the Internet security community, network security engineers and bot developers."
      NEW: "The detection and destruction of bots is an ongoing issue and also a constant battle between the Internet security community and network security engineers on the one hand and bot developers on the other."
      P2P is not a communication protocol, it is an architectural approach.
      It is a bit odd to speak of the "introduction" of HTTP, given that HTTP was invented over 20 years ago.
      The document sometimes conflates bots and botnets. For example:
      "As a consequence, botnets that are initially detected and classified by the ISP as one particular type of bot need to be continuously monitored and tracked in order to identify correctly the threat the botnet poses at any particular point in time."
      Although a botnet consists of bots, not all bots are part of a botnet (and we certainly can't say that a botnet can be classified as a type of bot, as in the quoted paragraph).

    Telechat:

3.2.2 Returning Items

  1. (none)

3.3 IRTF and Independent Submission Stream Documents

3.3.1 New Items

  1. Host/Host Protocol for the ARPA Network (Historic)
    draft-mckenzie-arpanet-host-host-protocol-01
    Token: Russ Housley
    Note: ISE document
    Discusses/comments (from ballot 4044):
    1. (none)

    Telechat:

3.3.2 Returning Items

  1. (none)

4 Working Group Actions

4.1 WG Creation

4.1.1 Proposed for IETF Review

  1. SPF Update (spfbis)
    Token: Pete

    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. Use and maintenance of datatracker.ietf.org/iesg/ann/ind , /new, and /prev (Robert Sparks)

    Telechat:

  2. Executive Session for IAOC Member Selection (Russ Housley)

    Telechat:

  3. Should RFC 3934 become part of BCP 25? (Russ Housley)

    Telechat:

7. Agenda Working Group News

1330 EST Executive Session for management issue 6.2


Valid HTML 4.01 Strict


Appendix: Snapshot of discusses/comments

(at 2011-12-15 07:30:05 PST)

draft-ietf-l3vpn-ospfv3-pece

  1. Jari Arkko: Comment [2011-12-14]:
    +1 to comments from Fred Baker and Dan Romascanu
  2. Stephen Farrell: Comment [2011-12-13]:
    - Who's the document shepherd? Tracker note says Ben, iesg writeup
    says Danny. Probably a typo somewhere or a change, but might be worth
    fixing.
    
    - The abstract is confusing. It says "We had BGP/MPLS for IPv4; then
    we added IPv6; then we added OSPFv2 and now in this document, we add
    OSPFv3." Telling the reader about IPv4/IPv6 just seems distracting
    here.
    
    - NLRI & NSSA not expanded on 1st use. 
    
    - Is it safe to use a NULL domain ID? If I do that then
    an incoming message can easily be confusing? 
    
    - Section 7 refers to rfc 4659 section 11 and 4577 section 6.
    4659 section 11 refers to 2545 section 5 and 4364 section 13.
    4577 refers to 4364 and 4365.
    2545 says "nothing new here."
    4364 is updated by 4577, 4684 and 5462.
    4577 says "cryptographic authentication" SHOULD be used and
    MUST be implemented but doesn't say what "cryptographic
    authentication" really means.
    I stopped following the breadcrumbs at that point;-)
    Can't we do this better and simpler?
  3. Dan Romascanu: Comment [2011-12-14]:
    Fred Baker made in his OPS-DIR review a couple of comments which are not show
    stoppers but deserve being answered and clarified if necessary in the text:
    
    1. The introduction mentions the use of OSPFv2 for IPv4 and OSPFv3 for IPv6.
    With the advent of OSPFv3 address families, mentioned in section 6, it is
    possible to use OSPFv3 for IPv4, enabling one protocol and one configuration to
    be used for both network layer protocols. I would expect that this might be a
    useful thing to comment on in the introduction.
    
    2. The one question I was left asking was why the document mentioned MPLS in 20
    places but did nothing with MPLS other than mention that it was used in BGP/MPLS
    VPNs. The routing technology could just as easily be used on any other PE-CE
    link; the point is that it is between an OSPFv3 instance in the PE and a
    correspondent on the CE router, enabling a customer to communicate with an
    upstream in a manner that enabled the upstream to trust routing information
    without the customer needing to obtain an AS number and operate a BGP
    configuration. That's not an impediment; the document only chose to specify that
    configuration. But the narrowness of specification left me puzzled.

draft-ietf-6man-rpl-option

  1. Jari Arkko: Comment [2011-12-01]:
    Sorry, posted the IANA issue in wrong tracker window...
  2. Ralph Droms: Discuss [2011-11-29]:
        1. The first sentence of section 4:
    
       Datagrams sent between RPL routers MUST include a RPL Option or RPL
       Source Route Header ([I-D.ietf-6man-rpl-routing-header]) and MAY
       include both.
    
    Under what circumstances would a RPL router include an SRH but not a
    RPL Option?
    
    2. This issue requires a little clarification before I can provide an
    actionable Discuss issue.  Is it possible to deploy RPL in a network
    in which not all of the nodes in the network participate in RPL?
    E.g., can there be "leaf" nodes, the equivalent of hosts, that do not
    participate in RLL and that exchange datagrams with immediate
    neighbors that are RPL routers?  There is a hint that such a
    deployment is anticipated in the phrase "attachment router" in section
    4.  If so, I think there needs to be additional text similar to that
    in section 5 describing how a RPL router must ensure that it doesn't
    forward a datagram containing a RPL Option to a non-RPL leaf node.
     
        
  3. Adrian Farrel: Comment [2011-11-30]:
    I have no objection to the publication of this document, but I have a umber of
    questions/nits that I hope you will consider.
    
    Section 1
    
      To that end, this document proposes a new IPv6 option,
    s/proposes/defines/
    
    ---
    
    Setion 2
    
       Every RPL router along a packet's delivery path processes and updates
       the RPL Option.  If the received packet does not already contain a
       RPL Option, the RPL router must insert a RPL Option before forwarding
       it to another RPL router. 
    
    Surely that means that the absence of the option indicates a defect in 
    the upstream router. This issue is also present in section 4 where there
    is some flexibility about whether to include the RPL Option, but no
    guidance.
    
    ---
    
    Section 3
    
    Please consider using RFC2119 language (e.g. "shall")
    
    ---
    
    Section 3
    
       Nodes
       that do not understand the RPL Option MUST discard the packet.
    
    You cannot state this in this way. Nodes that do not understand the 
    option will not implement this spec!
    
    You probably simply need:
    
    As defined in [foo] nodes that do not understand an option on a
    received packet MUST discard the packet.
    
    ---
    
    Sections 3 and 7
    
    Please check "sub-TLV" and "TLV". I think you have used them
    interchangeably.
    
  4. Stephen Farrell: Comment [2011-12-14]:
    
        
  5. Russ Housley: Comment [2011-11-28]:
      The Gen-ART Review by Joel Halpern on 22-Nov-2011 included a
      suggestion for improved clarity.  Please consider it.
    
       While calling a bit the O bit does not appear unreasonable, I
       note that when looking at the packet form, the difference between
       the O bit and the mbz bits marked as 0 is small, and a likely
       source of confusion for the reader.
  6. Robert Sparks: Comment [2011-11-29]:
    Please double-check the first paragraph of section 4 to make sure that "ICMPv6
    errors generated by inserting the RPL option" is really what you mean to say -
    are you talking about errors that resulted from inserting the option itself, or
    possibly other ICMP errors that might result from other data in the tunnel
    header?
  7. Sean Turner: Comment [2011-11-30]:
    I support Stephen's discuss.

draft-ietf-geopriv-deref-protocol

  1. Jari Arkko: Comment [2011-12-15]:
    Maybe I missed it or it is discussed in some other document, but I felt the
    document did not describe some basic properties of local references. For
    instance, if I ask for my location and then pass it on to someone else, is the
    resulting dereferenced location my location at the time of the request, or my
    current location? Devices can move...
  2. Stephen Farrell: Discuss [2011-12-12]:
        
    #1 The draft is (a little) inconsistent about the requirement to *use* TLS.
    Section 1, end of 3rd para says this "requires use of TLS", but
    elsewhere (e.g. section 4, 2nd para) you say that this defines how to
    use "http:" URIs and the security considerations says only that TLS is
    "strongly RECOMMENDED." I'd prefer it all to say that you MUST 
    use TLS always, but it at least needs to be consistent doesn't it?
    This should be an easy fix, I guess.
    
    #2 What, if any, form(s) of TLS server auth are required to be used
    when TLS is used? Would it be right to say a client MUST NOT not offer
    anonymous ciphersuites in the client hello? i.e the TLS_*_anon_*
    ciphersuites. (Just checking in case that hadn't been considered. 
    If it already was and there's a reason to allow anon ciphersuites
    that's ok but would be worth explaining.) 
        
  3. Stephen Farrell: Comment [2011-12-12]:
    - I expected to see some mention of single-use URIs here. Is there
    no use-case for those? It might help a bit given the 
    possession-is-authorizaiton model? (But it'd also conflict with other
    use-cases maybe.)
    
    - s3.1, maybe s/is constructed/MUST be constructed/ such
    that it is hard to guess?
    
    - what are the "other measures" mentioned in the 2nd last
    para of 3.1?
    
  4. Pete Resnick: Discuss [2011-12-14]:
        3.2/3.3: I cannot see how this protocol can be interoperable unless you commit
    to a particular policy mechanism and format, not just a "possible format" [3.2]
    or a mechanism "such as those described in [I-D.ietf-geopriv-policy]". It seems
    to me that ietf-geopriv-policy should be a normative reference in this document,
    not an informative one, and these two sections should be written to normatively
    reference it. 
        
  5. Pete Resnick: Comment [2011-12-14]:
    Section 1: Lots of redundant text. Could use an edit. A single paragraph is
    probably sufficient. I also find the diagram not terribly useful in the intro.
    
    Section 3: I actually found this discussion rather confusing and unnecessary.
    "Authorization by Posession" is often equivalent to no authorization at all. For
    certain resources that require no particular protection, there needn't be any
    obscuration by "hard to guess" URIs, and there needn't be a Rule Maker in
    existence at all. On the flip side, Authorization via Access Control needn't
    involve a policy document at all: regular HTTP authenthication could be used
    with a username and password, and access control can be handled entirely by the
    HTTP server, again without a Rule Maker. (Of course, in each case there is
    theoretically a "Rule Maker", but that is so theoretical as to make the entity
    of little use conceptually.) No matter the authorization and authentication
    used, Posession is still required, so I don't see that as a useful concept.
    
    I would be happy if this section simply eliminated the concept of "Authorization
    by Posession" and simply talked about different authorization and authentication
    methods. I think it would also be fine to leave this entire discussion to the
    policy document. But at the very least, I think you should mention that
    Authorization by Posession does not require a Rule Maker or a policy or making
    URIs hard to guess, though those are options to make access to location
    information more controlled.
  6. Peter Saint-Andre: Comment [2011-12-13]:
    The AppsDir review by Ted Hardie raised several minor issues, which deserve a
    response. The review can be found at http://www.ietf.org/mail-archive/web/apps-
    discuss/current/msg03941.html
    
    A number of terms are re-used from RFC 3693 and RFC 5808; it would be helpful to
    cite those specifications in Section 2.
    
    Although Section 3 says that "no authentication framework is provided", it's not
    true that authentication cannot be performed (e.g., if HTTP is used to
    communicate with the LIS/LS then HTTP authentication can be used). The text here
    is not entirely consistent with the later text in Section 3.3 ("A Location
    Server MAY support an authentication mechanism that enables identity-based
    authorization policies to be used") and similar text in Section 4.
    
    It would be appropriate to say something about leakage of location URIs (which
    could happen outside the TLS-protected channel between the Target and the
    Location Recipient -- URIs have a tendency to leak). RFC 5808 has some text
    about this, and perhaps you could simply point there.
  7. Sean Turner: Discuss [2011-12-14]:
        1) This is along the same lines as Stephen's #1.
    
    s3.1: Just to make sure I understand Authorization by Possession could just as
    easily have been called Authorization by Obscure URI?  These seems like security
    through obscurity.
    
    Also, shouldn't there be some kind of statement like at a minimum:
    
      The use of this model SHOULD involve the use of TLS?
    
    Actually based on s4 shouldn't that be a MUST?
    
    s4 contains the following:
    
      The Location Recipient establishes a connection to the LS, as
      described in [RFC2818].  The TLS ciphersuite TLS_NULL_WITH_NULL_NULL
      MUST NOT be used.  The LS MUST be authenticated to ensure that the
      correct server is contacted.
    
    I read that as HTTPS MUST be used.  If that is how you intended it, can't you
    just say that instead?
    
    s6 says s4 says it's strong RECOMMENDED, but I don't see that in s4. 
        
  8. Sean Turner: Comment [2011-12-14]:
    1) Figure 2: Shouldn't the two figures in the geo-priv drafts match?
    
    2) s3.1: Isn't it c8 in RFC 5808:
    
      (see C9 of [RFC5808])
    
    3) s3.1: Isn't this true only when you don't use S/MIME:
    
      Use of authorization by possession location URIs in a hop-by-hop
      protocol such as SIP [RFC3261] adds the possibility of on-path
      adversaries.
    
    4) s3.2: strike the a:
    
      In contrast to authorization by possession, possession of a this
      form of location URI does not imply authorization.
    
    5) s3.2: I think you need to work something about authorization by access
    control being based on an authentication mechanism.  You mention in s3 and then
    again in s3.3, but it seems like it needs to be included in s3.2.  I kept
    thinking .. because … after the first sentence. Maybe:
    
      Use of explicit access control provides a Rule Maker greater
      control over the behaviour of an LS because it determines access
      based on individual Location Recipients.
    
    or something like that.
    
    6) s3.3: In the first two paragraphs of s3.3, I think you're trying to say this:
    
      This document does not describe a specific authentication
      mechanism; therefore, the authorization by access control
      model is not an option.  Instead, this document uses the
      authorization by possession model.
    
    The existing two paragraphs seemed little wordy.

draft-ietf-geopriv-policy-uri

  1. Jari Arkko: Discuss [2011-12-15]:
        I will probably clear this after some discussion in the IESG tonight, and let
    Stephen hold his Discuss (item #5 in particular).
    
    However, I am concerned that the document provides an authorization-by-
    possession model for clients to access their policies, delivers the policy URLs
    in the same DHCP and XML structures as other location URLs, and also
    acknowledges that there is a legitimate need for other entities to access
    policies:
    
       This document does not describe
       how policy might be provided to entities other than for location
       configuration, for example, in responses to dereferencing requests
       [I-D.ietf-geopriv-deref-protocol] or requests from third parties
       [RFC6155].
    
    I predict that policy URLs will be leaked, intentionally, to those who need
    them, and that this will lead to security issues down the road. Is there
    something that we could do about this? 
        
  2. Stephen Farrell: Discuss [2011-12-12]:
        #1 Intro para 2 says that the deref protocol provides a PEP, but just
    having read it, it doesn't, except for in that very very limited sense
    of supporting authorization-by-possession. So the claim seems wrong.
    I'd say just removing the claim is easiest.
    
    (I guess I agree with Tobias' Apps area review points being a discuss,
    so... I've broken the overall points down into a number of specific
    things below, hopefully that'll help get 'em sorted quicker.)
    
    #2 Why even allow HTTP URIs? Why not insist on HTTPS for this?
    geopriv-deref does (almost correctly) insist on use of TLS so it seems
    illogical for this to be more open. In any case, the same choices would
    be best for both of these specs I think wrt TLS usage. 
    
    #3 For the case where a policy URI is a "shared secret," what TLS
    server auth settings are required to be used? Would it be good to say
    the client MUST NOT offer TLS_*_anon_* ciphersuites in the client
    hello?
    
    #4 Saying the policy server SHOULD allow all requests (3.1 2nd para)
    seems unwise. It may be reasonable to allow for the URI-is-secret
    model, but I don't get why you want to prevent anything more? (That's
    how I interpret the SHOULD.) Saying (at the end of section 3) that a
    new policy URI MUST be generated whenever a new location URI set if
    generated also seems to work against any other (better;-) kind of
    authorization.
    
    #5 Assuming URIs remain secret seems problematic. Is there evidence
    that the confidentiality of these URIs can be maintained really?
    
    #6 Describing the policy URI as a shared secret doesn't seem to be
    enough. I think you need to say that it MUST be a practically
    unguessable shared secret, even if I have seen many such URIs. The DHCP
    option in 4.2 means that anyone can I guess get the server to emit
    loads of policy URI values. 
    
    #7 Why is it reasonable to have a default of making location available
    (to possessor's of the URI)? Couldn't that be dangerous in conjunction
    with some other defaults (e.g. some other protocol might default to
    including a location URI in a message), or is there somewhere in
    geopriv where it says that the overall default is that location
    information has to be denied by default?
    
    #8 Why not acually define a good policy URI generation function rather
    than give all these partial hints? I don't even necessarily mean as a
    MTI but rather as a good example of how to do it.
    
    #9 What is the argument that 2^32 unique policy URIs is a big enough
    number? 
    
    #10 (2^(N/2))/T is meant to restrict an unlimited attacker to one
    successful guess per T seconds? Is that correct and the intent?  Be
    better to explain your logic there. If that is the intent, I don't see
    why its considered a good thing. (Be fun to sse if my arithmetic is
    screwed up there or not;-)
    
    #11 What are the likely values of T that will be used? It seems odd to
    only introduce a lifetime value like this at this point.  Maybe you
    mean that T is some value derived from system behaviour rather than a
    parameter? If the former, then is it reasonable to expect the rate
    limiting enforcement function to have that number available to it?
     
        
  3. Stephen Farrell: Comment [2011-12-12]:
    - Just adding 32 random bits to the mix might not be enough if you have
    ~ 2^32 clients. Worth noting? 
    
    - 2^(N/2)/T is likely to be error-prone. One more set of parenthesis
    would be good.
    
  4. Pete Resnick: Comment [2011-12-13]:
    Please consider the review of Tobias Gondrom <http://www.ietf.org/mail-
    archive/web/apps-discuss/current/msg03926.html>. I will defer to the expertise
    of the Security ADs to consider whether the issues he points out are worthy of
    DISCUSSion, but I have not seen a public reply to his message.
    
    [Updated to add:]
    I note from the writeup that there are no implementations of
    this. I also note that geopriv-policy is given as an example of what might be
    used as a policy document in addition to the others. Is my suspicion correct
    that, in fact, down the road geopriv-policy will be the *predominant* use of
    this URI? If so, is it not worth holding this document until that one is
    completed? I suspect it will end up a lot shorter if it could talk in terms of
    an actual GEOPRIV policy document and use the others only as examples. (I see no
    need to hold a DISCUSS position on this, as I think there is no harm in
    publishing this first, but I would like to hear from the authors/chair/WG as to
    what the reasoning was.)
  5. Peter Saint-Andre: Comment [2011-12-13]:
    I concur with the DISCUSS position of Stephen Farrell.
    
    Why does this specification use the term "Internet host" instead of the term
    "Target" from RFC 3693? Consistency across this suite of documents would be
    good.
    
    It would be helpful to cite RFC 3693 and RFC 5808 in Section 2.
    
    In Section 4.1, the schema references
    "urn:ietf:params:xml:ns:geopriv:held:policy" but that namespace is never used in
    the schema definition.
    
    In the examples, it would be helpful to point to the specifications that define
    the various data structures (i.e., the "urn:ietf:params:xml:ns:geopriv:held",
    "urn:ietf:params:xml:ns:common-policy", and "urn:ietf:params:xml:ns:geolocation-
    policy" namespaces).
    
    The second block of XML in Section 5.3 never defines the gp: prefix (i.e., you
    need to add xmlns:gp="urn:ietf:params:xml:ns:geolocation-policy" to the root
    <ruleset/> element).
  6. Sean Turner: Comment [2011-12-15]:
    I'm with Stephen and Jari on this one and definitely support Stephen's discuss.
    This really feels like security through obscurity, but if I let you see mine
    then you can be me for while.

draft-ietf-simple-msrp-cema

  1. Stephen Farrell: Discuss [2011-12-14]:
        #1 Lawful intercept is not a feature in this context (see rfc 2804)
    I'd say just delete the phrase and you'll loose nothing.
    
    As you'll see from the points below I have some issues with how
    you're using TLS. Could be that some of this is just a lack
    of context on my part but I'd like to check at least.
    
    #2 What name is authenticated in "name based authentication"? Would
    any such name (in a cert issued by a locally trusted CA) do just
    fine?  
    
    #3 2nd para of 7.2: if an MSRP endpoint can get an "incorrect
    impression" about TLS in the presence of a middlebox then how does
    the MSRP endpoint ever benefit from authentication?
    
    #4 How is the MIKEY reference not normative? 7.2 RECOMMENDS doing
    either 1) TLS certs with blah (RFC 6042) or 2) MIKEY stuff. The
    MIKEY RFC (RFC 6043) is informational so that's a downref. 
    
    #5 I don't understand how MIKEY for managing TLS-PSK values is
    well-defined. The string "TLS" does not occur in RFC 6043.  (I'd
    just drop the MIKEY idea entirely - is anyone really gonna do that?)
    
    #6 Can you re-assure me that there are in fact implementations of
    RFC 6072 and RFC 6043 (in the latter case usable for managing
    TLS-PSK symmetric keys). If so, great, I'd appreciate some pointers
    to those. If not, then are you really building on fiction? Wouldn't
    that be a bad plan?
    
    #7 I don't get the trust model for "fingerprint" based
    authentication for TLS. Who's including the fingerprint where and
    using it to verify what self-signed cert?
    
    #8 How do MSRP endpoints figure out what authentication methods
    they have in common in a way that's not attackable by an on-path
    active attacker? What is the list of "mechanisms" that you
    mean in 7.2 (para starting with "If possible, ...")
    
    #9 I get the impression that the 2nd last paragraph of 7.2 is
    what you think people will actually do and that all the rest
    of that section is window dressing. Am I wrong? If I'm right,
    then why not just plainly say that and then we can discuss
    it more easily?
    
    #10 If I'm wrong about #9: On what basis can an MSRP endpoint
    pick between the two choices at the end of 7.2? What code do
    I write?
     
        
  2. Stephen Farrell: Comment [2011-12-14]:
    - the term "anchor" is never really explained and it'd be good to do
    that.
    
    - hard to parse this from the top of p4: "In such cases,
    middleboxes, that want to anchor the MSRP connection simply modify
    the SDP c/m-line address information, similar to what it does for
    non-MSRP media types" who's the last "it"?
    
    - "The CEMA extension is fully backward compatible." Seems a bit of
    sales-talk. And (fully;-) backwards compatible with what?
    
    - "Middleboxes cannot be deployed in environments that require
    end-to-end SDP integrity protection or SDP encryption." I bet I
    could deploy a middlebox in such an environment, perhaps not very
    effectively, but I could. "Cannot" cannot be correct.
    
    - In general, I'd ask you to think about describing TLS usage in section
    7 from the point of view of the TLS endpoints and not based on the 
    various options for what a middlebox might do. I suspect that might lead to
    a clearer description but hard to know unless you try.
  3. Pete Resnick: Comment [2011-12-10]:
    Section 3:
       "Support of the extension is optional."
    
    Do you mean "OPTIONAL"?
    
       "MSRP endpoints that
       support CEMA are required to use RFC 4975 behavior in cases where
       they detect that the CEMA extension cannot be enabled."
       
    Do you mean "REQUIRED"?
    
    Section 4.1:
    
       In the following cases, where there is a Middlebox in the network,
       the CEMA extension cannot be used...
    
    Do you mean "MUST NOT be used"?
    
    Section 4.2:
    
       When the offerer receives an SDP answer, if the MSRP media
       description of the SDP answer does not contain an SDP 'msrp-cema'
       attribute, the offerer MUST check the criteria below.  If either or
       all of the criteria is met, the offerer MUST fallback to RFC 4975
       behavior, by sending a new SDP offer according to the procedures in
       RFC 4975 and RFC 4976.
    
    This is mostly editorial, but since it involves 2119 language, I think it's
    worth fixing: The first MUST is redundant. If the offerer MUST do things based
    on the criteria, there is no need to say that you MUST check the criteria.
    (Also, "either" is the wrong word when there are more than two criteria. You
    meant "any".) Instead maybe:
    
       The offerer MUST fallback to RFC 4975 behavior, by sending a new
       SDP offer according to the procedures in RFC 4975 and RFC 4976, if
       it receives an SDP answer whose description does not contain an SDP
       'msrp-cema' attribute, any of the following criteria are met:
       
       [1...
        2...
        3...]
       
       The new offer MUST NOT contain an SDP 'msrp-cema' attribute.
    
  4. Peter Saint-Andre: Comment [2011-12-07]:
    It seems to me that the security considerations are somewhat underspecified, and
    I find the concept of a TLS B2BUA unsatisfying, but I will let folks from the
    security area comment on those aspects of the specification.
  5. Robert Sparks: Discuss [2011-12-13]:
        There are two paragraphs in section 7.2 (the ones starting "When an MSRP
    endpoint" and "If possible, MSRP endpoints") that need to be scoped to this
    extension. It might be enough to say CEMA-enabled MSRP endpoint everywhere you
    currently say MSRP endpoint, but that would likely make the text hard to read.
    
    There's something wrong with the second paragraph and the list that follows it.
    It currently says "Check every authentication mechanism at your disposal. If
    they all fail, then based on local policy, decide whether you want to believe
    the failure is because there is a benign network that's trying to help you
    instead of a malicious party trying to hurt you." Is that what the document was
    actually trying to say? If so, then if you're going to allow an endpoint to make
    that decision (and I don't think you should since there's no way to tell that
    all the network elements are actually part of that benign network), why waste
    the time authenticating in the first place? Unless the paragraph intended
    something completely different, option 2 in the list should be removed. 
        
  6. Robert Sparks: Comment [2011-12-13]:
    The short title that appears on every page but the first needs to be changed.
    It's currently MRSP. CEMA or MSRP-CEMA would be better.
    
    In section 4.2, "either or all of the criteria" is unclear. I suggest "any of
    the following criteria" instead.
    
    In 4.2 and 4.3, there are notes about resolving domain names before trying to
    match against addresses in c or m lines in SDP. They currently say "whether
    there address". I suggest "whether the address" instead.
    
    In section 4.4 when you discuss handling multiple records from DNS, it's not
    clear whether all the resolved addresses must match or only one in the set must
    match.
  7. Sean Turner: Discuss [2011-12-15]:
        s7.1: I believe the following requires a normative reference to TLS:
    
       For backward compability, a CEMA-enabled MSRP
       endpoint MUST implement TLS.
    
    s7.2: What is "a common authentication mechanism" in following:
    
      If possible, MSRP endpoints MUST use name-based authentication.  If
      not possible, if the MSRP endpoints support a common authentication
      mechanism, they MUST use that mechanism.  If the MSRP endpoints do
      not support such common authentication mechanism, they MUST try
      fingerprint-based authentication, which will succeed if there are no
      Middleboxes present.  If that also fails, the MSRP endpoints MUST
      either:
    
        
  8. Sean Turner: Comment [2011-12-15]:
    s1: strike lawful intercept (I see Stephen made this a discuss otherwise I would
    have made it one too)
    
    s2: Fingerprint Based TLS AUthentication:
        r/self-signed TLS certificate/self-signed certificate
        r/fingerprint/fingerprint (i.e., a hash of the self-signed certificate)
    
    s2: Name Based TLS Authethication
        r/certificate authority/certification authority
        r/SubjectAltName parameter/SubjectAltName extension
    
    s3: r/Support of the extension is optional./
          Support of the extension is OPTIONAL.
    
    s7.2: certificates are by definition public so I'm a little confused by the
    following:
    
      1.  TLS certificates together with support of interacting with a
          Certificate Management Service [RFC6072], to which it publishes the
          public version of its own self-signed certificate and from which it
          fetches on demand the public certificates of other endpoints.
    
    Maybe: 
    
      1.  TLS certificates together with support of interacting with a
          Certificate Management Service [RFC6072], to which it publishes
          its self-signed certificate and from which it
          fetches on demand the self-signed certificates of other endpoints.
    
    s7.2: (Stephen caught this too) MIKEY-TICKET is a normative reference.
    
    s7.2: I share the same concerns Stephen has wrt the fingerprint authentication.
    
    s7.3: Probably worth a pointer to the SIP issues based on the following:
    
      Even with seemingly end-to-end media integrity, at the time of the
      publication of this document there are other vulnerabilities in MSRP,
      due to vulnerabilities in the SIP signaling.

draft-ietf-tcpm-rfc3782-bis

  1. David Harrington: Comment [2011-12-13]:
    I read the document. I got a bit lost in the details.
    The document appears to be well-written.
    
    in section 2,
      This document assumes that the reader is familiar with the terms
    SENDER MAXIMUM SEGMENT SIZE (SMSS), CONGESTION WINDOW (cwnd), and
       FLIGHT SIZE
    (FlightSize) defined in [RFC5681].  FLIGHT SIZE is
       defined as in [RFC5681] as
    follows:
    If you assume the reader is familiar with the FLIGHT SIZE definition,
    why repeat it here?
    If you repeat the defintion of  flight size here, why not
    SMSS and CWND as well?
    
    It would have been good to have a tsvdir review of this document.
    
  2. Russ Housley: Discuss [2011-12-14]:
        
      The Gen-ART Review by Ben Campbell on 21-Nov-2011 against -03 of
      this document raised several concerns.  Draft -04 has been posted,
      but none of the concerns were addressed, nor was Ben told why his
      concerns were incorrect.
      
      Please respond to these concerns from Ben's Gen-ART Review:
    
      -- Appendix A refers the reader to RFC 3782 for additional
         information. But this draft purports to obsolete that RFC.  If
         there is important information in it that document that is not
         covered by this draft, then it doesn't really obsolete it. Is
         there a reason that information was not brought forward into
         this draft?
    
      -- There is very little RFC 2119 normative language. On a quick scan,
         I see one capitalized SHOULD NOT and one MAY. Yet it seems like
         there are other statements that are just as important for correct
         behavior as those. For the sake of consistency, it might be
         easiest to just drop the RFC 2119 language entirely. 
        
  3. Russ Housley: Comment [2011-12-14]:
      Please consider the comments raised in the Gen-ART Review by
      Ben Campbell on 21-Nov-2011.  The review can be found here:
      http://www.ietf.org/mail-archive/web/gen-art/current/msg06919.html

draft-ietf-6man-rpl-routing-header

  1. Ralph Droms: Discuss [2011-11-29]:
        I have two Discuss issue that should be easy to resolve.
    
    1. I think there is an inadvertent omission of some text.  From
    section 4.2:
    
       When forwarding an IPv6 datagram that contains a SRH
       with a non-zero Segments Left value, if the IPv6 Destination Address
       is not on-link, a router SHOULD send an ICMP Destination Unreachable
       (ICMPv6 Type 1) message with ICMPv6 Code set to (TBD by IANA) to the
       packet's Source Address.
    
    There should also be text explicitly requiring that the router drops
    the datagram.
    
    2. This issue requires a little clarification before I can provide an
    actionable Discuss issue.  Is it possible to deploy RPL in a network
    in which not all of the nodes in the network participate in RPL?
    E.g., can there be "leaf" nodes, the equivalent of hosts, that do not
    participate in RLL and that exchange datagrams with immediate
    neighbors that are RPL routers?  If so, I think there needs to be
    additional text similar to that in section 5 describing how a RPL
    router must ensure that it doesn't forward a datagram containing an
    SRH to a non-RPL leaf node. 
        
  2. Ralph Droms: Comment [2011-11-30]:
    Comment added on 11/30.
    
    The working group summary is pretty terse.  I think it would be
    helpful to explain that the design and use of the option morphed
    several times during the working group discussion before
    it arrived at its current state.  Also, the working group summary
    should refer to the roll (not RPL) working group.
  3. Adrian Farrel: Comment [2011-11-30]:
    I have no objection to the publication of this document, but I have a number of
    small editorial questions/comments that I hope you will address along the way.
    
    Section 2
    
       First, RPL routers implement a strict source route policy where each
       and every IPv6 hop is specified within the SRH.
    
    appears to be in conflict with
    
       2.  If the SRH only specifies a subset of the path from source to
           destination, the router uses IPv6-in-IPv6 tunneling [RFC2473]
    
    This probably just needs clarifying text in the paragraph. There is 
    explanation of when the situation occurs (after the numbered list).
    
    ---
    
    Section 3 Next Header
    
    Shouldn't your base reference be RFC 2460? If IPv6 was to choose to 
    diverge from IPv4, which one would you follow?
    
    ---
    
    Section 3 Routing Type
    
    You do not mention the use to which this field is put anywhere in your
    document. It should probably go here.
    
    ---
    
    Section 3 Reserved
    
    You have not said how the Reserved field is handled.
    
    ---
    
    It would have been useful to state (section 4.1?) how "segments left"
    is set on the initial SRH and whether the first entry in the address
    list includes the source node.
    
    ---
    
    Section 4.2
    
              else if 2 or more entries in Address[1..n] are assigned to
                      local interface and are separated by at least one
                      address not assigned to local interface {
    
    This check is more specific than the text previously indicated. This 
    is the first mention of non-adjacent repeat addressing.
    
    ---
    
    Section 4.2
    
                 swap the IPv6 Destination Address and Address[i]
    
    Do you really mean swap? Or do you just want to set DstA = Address[i] ?
    
    ---
    
    Section 4.2
    
    I'm surprised that you check and decrement the hop limit so late in the
    cycle.
    
  4. Stephen Farrell: Comment [2011-12-14]:
    
        
  5. Robert Sparks: Comment [2011-11-29]:
    
      

draft-ietf-l2vpn-arp-mediation

  1. Jari Arkko: Discuss [2011-09-22]:
        I am reading the ND modifications and trying very hard to convince myself that
    they are correct and complete. I'm not 100% sure I've managed to do that.
    
    I scanned the mailing list for 6man and found no discussion of this draft. Did I
    miss it? Shouldn't relatively complex surgery on ND require some review from the
    experts on ND?
    
    I'm also wondering if the SEND proxy specification from CSI WG would be an
    applicable recommendation in addition to recommending turning SEND off.
    
    To be more specific, can you:
    
    1) perform a 2-week last call in 6MAN for additional review, and
    2) either point
    to the use of the SEND proxy specification or provide reasons why it cannot be
    used 
        
  2. Ralph Droms: Comment [2011-09-21]:
    In section 4.3.3, is "the link-layer address of the
    local AC" really "the link-layer address of the PE
    interface attached to the local AC"?
  3. Adrian Farrel: Discuss [2011-09-22]:
        I will move to a "Yes" ballot when my Discuss has been resolved.
    
    Why does this document include a redefinition of the Address List TLV
    that is already defined in RFC 5036? Although the text says that it is
    using the RFC 5036 definition, the text also says that the I-D defines
    the Address List TLV.
    
    Shouldn't you simply refer to 5036 and say how the fields are set for
    your specific use?
    
    Similarly the redefinition of the Notification message.
    
    To be clear, the main reason for objecting to the redefinition is that
    it opens the door to discrepencies, and makes it hard to handle
    future extensions. (Coders should be familiar with the practice of
    only defining data structures in one place :-)
    
    ---
    
    Please add some text to clarify whether the Stack Capability field   
    in the Stack capability Interface Parameter sub-TLV is an integer or
    a bit-field.
    
    The IANA section makes it look like a bit field (which is what I 
    would expect) but the text in the main body says...
    
         Stack Capability = 0x0001 to indicate IPv6 stack capability 
    
        
  4. ...which makes it look like an integer Additionally, the text goes on to imply that the interpretation of the field is context-specific... The value of Stack Capability is dependent on the PW type context. For IP Layer2 Transport type, a setting of 0x0001 indicates IPv6 stack capability.
  5. ...if this is the case, presumably, 0x0001 could mean something else in other circumstances. How is this tracked in the IANA registry?
  6. Adrian Farrel: Comment [2011-09-22]:
    Should the figure on page 5 include the label "AC3"?
                
    ---
    
    I agree with the other ADs who are concerned about the use or non-use
    of RFC 2119 language. Hopefully, this will be easy for you to clean up
    and will not be construed as changing the technical content of the
    document.
    
    ---
    
         The "IP Layer 2 interworking circuit" 
         pseudowire is also commonly referred to as "IP pseudowire". 
    
    Can you insert a reference for "IP pseudowire"?
  7. Stephen Farrell: Comment [2011-09-16]:
    - 8.1 says that you "can" secure the PE-PE control plane "using MD5
    authentication." Is that (still) the best that can be done? Doesn't
    it need a reference? Why can't something better be used, e.g. IPsec?
    Why no 2119 language? (This isn't a discuss because I hope that
    all that's in some other RFC.)
    
    - 8.1 says that this protocol is incompatible with SEND. I
    guess that's inevitable, but do you need to say more about
    the trade-offs concerned, e.g. would it ever be likely that
    a CE that depends on SEND is deployed and later on a PE doing
    this protocol is installed breaking the CE or changing its
    security properties in a bad way? (Just wondering.)
    
    - Frame Relay (FR) is expanded only on its 2nd use. 1st
    use is in 2nd para of section 1.
  8. David Harrington: Discuss [2011-12-14]:
        1) in section 2, it says IPv4 L2 interworking MUST be supported, but it is only
    a SHOULD for IPv6.
    Why is IPv6 mediation not a MUST for PEs?
    
    (please note that draft-ietf-intarea-ipv6-required-02 is in IESG Eval for
    Proposed Standard. It hans't been approved yet, but probably will soon.)
    
    2) in 3, "In this case, all data link headers are removed to expose the IP
    packet at the ingress." should this be MUST remove?
    3) in 2, "Intercept Neighbor
    Discovery and Inverse Neighbor Discovery packets received over the pseudowire
    from the remote PE, possibly modifying them (if required for the type of
    outgoing AC) before forwarding to the local CE,"
    Can the RFC2119 language make
    "possibly if required" less ambiguous? Does possibly mean "MUST if REQUIRED" or
    "SHOULD if REQUIRED" or "MAY if REQUIRED"?
    and please make sure this section is
    consistent with section 3, "In the case of an IPv6 L2 Interworking Circuit, the
    egress PE MAY modify the contents of Neighbor Discovery or Inverse Neighbor
    Discovery packets ..." 
        
  9. Russ Housley: Comment [2011-09-21]:
      The Gen-ART Review by Peter McCann on 20-Sep-2011 raised a minor
      issue and two editorial suggestions:
      
      Section 5.2 says: "Since this notification does not refer to any
      particular message the Message ID and Message Type fields are set
      to 0."  There does not appear to be a Message Type field in the PDU.
    
      Section 5: suggest replacing the idiom "chicken and egg situation"
      with "possible deadlock situation."
    
      Section 5.2: "Section 6. below." should be "Section 6 below."
  10. Pete Resnick: Comment [2011-09-21]:
    1. This entire document needs a good "MUST/SHOULD/MAY vs. must/should/may"
    scrubbing. Just to cite two examples:
    
    4.2.2:
             
         When the PE learns the IP address of the remote CE, it should 
         generate an Inverse ARP request.
    
    It "should"? Or it "SHOULD"? Or it "will"?
    
    4.3.2:
    
         If a Router Discovery message contains a link layer 
         address, then the PE MAY also use this message to discover the 
         link layer address and IPv6 interface address.
    
    That MAY doesn't sound like a protocol option.
    
    2. Section 2:
    
         PEs MUST support ARP mediation for IPv4 L2 Interworking 
         circuits. PEs SHOULD support ARP mediation for IPv6 L2 
         interworking circuits.
    
    I assume this means "PEs that support ARP mediation MUST support it for IPv4 and
    SHOULD for IPv6". The way it is now, it sounds like ALL PEs must support this,
    which can't be right. That said, I see no reason for this paragraph. Mediation
    should be supported on both v4 and v6 circuits. I say drop the paragraph.
    
    3. For the record, and not something the authors need to address:
    
    I understand that the IETF doing sub-IP protocols is a ship that has sailed long
    before I got on the IESG. However, the mind boggles that we are deploying this
    particular protocol: Why can't we simply *route*?!?!? This protocol is standing
    on its head to allow layer 2 bridging of IP across disparate links instead of
    just having a routed VPN. This is goofy, it is a complete layer violation, and I
    don't think we should be standardizing this nonsense.
    
    There, I feel marginally better. :-/
  11. Peter Saint-Andre: Comment [2011-09-21]:
    This document appears to be predicated on "know[ing] that only IP traffic will
    be carried". How is this determined?
  12. Robert Sparks: Comment [2011-09-21]:
    Section 7.2 invokes an IANA well known policy of "IETF Consensus", referencing
    RFC5226, but that RFC has renamed that particular policy to "IETF Review".
  13. Sean Turner: Comment [2011-09-22]:
    I have the same question Stephen did about MD5.

draft-gundavelli-v6ops-pmipv6-address-reservations

  1. Jari Arkko: Comment [2011-10-20]:
    
        
  2. Ralph Droms: Comment [2011-09-07]:
    There seem to be a couple of syntax issues in this text:
    
    OLD:
    
       The base Proxy Mobile IPv6 [RFC5213] all though required the use of a
       fixed link-local and a fixed layer-layer address,
    
    NEW:
    
       Although the base Proxy Mobile IPv6 [RFC5213] requires the use of a
       fixed link-local and a fixed link-layer address,
  3. Wesley Eddy: Comment [2011-08-30]:
    I think this is a useful document.  It seems like it should have "Updates: RFC
    5213" though?
  4. Adrian Farrel: Comment [2011-09-06]:
    Section 1
    
       To address this problem, this specification makes the
       following two reservations.  The mobility elements in the Proxy
       Mobile IPv6 domain MAY choose to use these fixed addresses.
    
    Stumbled over this because it looks like the second sentnece is a reservation
    (i.e. a modification to the base spec), but there is only one reservation
    listed.
  5. Pete Resnick: Comment [2011-09-05]:
    Strike section 2.1. 2119 is not used in this document.

draft-weil-shared-transition-space-request

  1. Jari Arkko: Comment [2011-12-01]:
    FWIW, the issue that I had with the previous incarnation of this document has
    been resolved. Thanks for working through the measurements and evidence about
    risks, and documenting them.
    
    However, my fellow AD colleagues have raised other issues (including status of
    IETF consensus for this document). I defer to them on those issues.
  2. Ron Bonica: Discuss [2011-11-29]:
        I will change this ballot to "YES" when a /10 has been allocated for this space. 
        
  3. Stewart Bryant: Discuss [2011-11-29]:
        I understand the commercial imperatives that the ISPs face, and appreciate this
    is a dilemma.
    
    However, the authors have not so far generated an adequate degree of consensus
    (as evidenced by discussions on the IETF list) that the deployment of this
    technology "makes the Internet work better". Indeed section 5 indicates that the
    deployment of this technology makes the Internet worse by reducing it to a
    network that only supports a limited range of services (Web, Mail and IM)
    sanctioned by the ISP. This seems contra to the mission of the IETF.
    
    If this were a clearly defined limited application network, a case could be
    developed for accepting restrictions, but the application described here is
    connectivity to the Internet and hence access to new innovative services.
    
    The authors need to gain consensus in the IETF, that there is no other solution
    to the problem in hand, and hence that the significant restriction on the type
    of user application supported is justified. 
        
  4. Ralph Droms: Discuss [2011-11-30]:
        I am posting a Discuss position for this document because the IESG
    should discuss some fundamental issues of how we should make a
    decision about publication of this document.
    
    I also have concerns about whether the IESG is the appropriate body to
    approve this request.  I intend to post an Abstain position after
    my questions are answered and I clear my Discuss.
    
    The conversation about this document and any attempt to determine
    consensus is difficult because the issues are technical, economic,
    political and psychological.  We (the IESG) are well-equipped and
    responsible for decisions about technical issues, but less so for the
    other issues.
    
    I've been reading most of the e-mail in the consensus call on
    ietf@ietf.org.  Here are some of the questions I think I've seen
    discussed:
    
      Does the assignment of the requested /10 enable or hinder the
      deployment of IPv6?
    
      Is CGN a viable service model for IPv4?
    
      Is the reserved /10 required for the deployment of CGN?
    
      Can the deployment of CGN be prevented by not assigning Shared CGN
      address space?
    
      What is the effect of burning 4 million IPv4 addresses on the
      exhaustion of IPv4?
    
      Can alternative /10s be used such as 10.64.0.0/10 or 240.0.0.0/10?
    
      How many ISPs really want this assignment and how many don't care
      because they don't need it?
    
    Most of these questions are, in fact, not technical questions and I
    don't think the IESG can answer them.  The document itself addresses
    only a few issues, giving one reason not to use each of the
    alternatives:
    
       o  legitimately assigned globally unique address space
       o  usurped globally unique address space (i.e., squat space)
       o  [RFC1918] space
    
    In particular, the reason for not using RFC 1918 space is simply
    asserted with no support facts.
    
    If the IESG is to make a decision, I would like to walk through the
    following questions:
    
      Is the IESG the appropriate body to make the decision?  If no, where
      should the decision be made, perhaps with technical advice from the
      IETF?
    
      Should the IESG identify any specific /10 for use as Shared CGN
      Space?  If no, do not approve the document.
    
      Does this document describe the usage scenarios, constraints and
      caveats sufficiently well to allow the use of a /10 as Shared CGN
      Space?  If no, ask for a revision.
    
      Should the IESG approve a request to IANA for a /10 as described
      in the document?  If yes, publish the document.
    
      Should the IESG request that IANA identify some other /10 (or
      similar address block), such as 172.16.0.0/12, 10.64.0.0/10 or
      240.0.0.0/10 for use as Shared CGN Space? 
        
  5. Wesley Eddy: Comment [2011-11-30]:
    I agree with the comments and discuss positions from others that say there is
    not IETF consensus on this document.
  6. Adrian Farrel: Comment [2011-11-30]:
    I concur with Stewart that there does not appear to be IETF consensus around
    this I-D.
    
    I am concerned that the alternative to this has been presented as "if you don't
    allocate the address space, the ISPs will just squat on another space." However,
    this also seems to be less worser than any other proposal on the table.
  7. Stephen Farrell: Comment [2011-12-08]:
    Based on more and more and more and more discussion I'm reluctantly 
    ok with this.
    
    I think additionally allocating part of 240/4 would be a fine thing to do at
    the same time within the same document. I would not be that keen on 
    punting on the 240/4 part allocation until later since that would engender
    most of the same discussion.
  8. David Harrington: Discuss [2011-12-13]:
        I believe there is not IETF Consensus for approving a /10 for this purpose, and,
    as a result, there is not IETF consensus to approve this document.
    
    This document describes a number of problems that occur with CGN, even with this
    shared /10, so CGN does not make the Internet run better. I think there is IETF
    consensus that widespread deployment of CGN could be damaging to the Internet. I
    believe approving Shared CGN space to make CGN deployment easier is counter to
    the IETF mission of making the Internet run better, and approving allocation of
    this /10 does not represent IETF consensus.
    
        
  9. Pete Resnick: Discuss [2011-12-01]:
        Calling out one piece of Ralph's DISCUSS directly: I agree with Ralph and
    Stephen that the question of whether there is another existing block of
    addresses that will cause less potential application damage and is still usable
    by CGNs (e.g., 10.64/16, 172.16/12, 240/10) has not yet been sufficiently
    answered. The proponents have claimed that there is full *use* of the 1918
    space, but not whether there is full use *by* devices that can't deal with 1918
    address space on their "external" interfaces. Until that question is answered,
    we can't tell if the risk of application damage really is outweighed by the risk
    to deployment. 
        
  10. Pete Resnick: Comment [2011-12-01]:
    I agree with Ralph's DISCUSS: We need to first come up with a list of criteria
    by which consensus can be judged. While I agree with most folks that there is
    *disagreement* on the list as to whether this allocation should be made, I think
    some of the issues on which there is disagreement are not legitimate criteria
    for the consensus call. (For example, "Is CGN a viable service model for IPv4?"
    is *not* something that we should be using as a criteria for consensus.) Before
    we come to a conclusion on consensus, we need to lay out the legitimate issues
    being discussed and whether there is consensus on each of them.
  11. Dan Romascanu: Discuss [2011-12-01]:
        Ralph sumarized well and in details the reasons for which the IESG cannot
    approve this document under its current form and at this point in time. I  will
    probably change my DISCUSS into an Abstain after the telechat, unless we come
    with a different plan of action. 
        
  12. Peter Saint-Andre: Comment [2011-12-08]:
    Based on list discussion, I have come to the conclusion that this is the least
    worst workaround (not "solution") available to us at this time.
  13. Robert Sparks: Discuss [2011-12-01]:
        While I personally agree with the position that approving this allocation is the
    least bad of the available choices, I don't believe IETF consensus for approving
    this document as it is currently written exists. 
        
  14. Robert Sparks: Comment [2011-12-01]:
    I encourage pursuing Ralph's questions and carefully separating the question of
    allocating the address space and what effect CGNs may have on the Internet.
  15. Sean Turner: Comment [2011-12-01]:
    I agree with Ralph.

draft-ietf-ccamp-wson-impairments

  1. Ron Bonica: Comment [2011-12-13]:
      == Missing Reference: 'Eppstein' is mentioned on line 1020, but not defined
    
      == Missing Reference: 'RFC5920' is mentioned on line 1138, but not defined
    
  2. Stephen Farrell: Comment [2011-11-26]:
    
        
  3. Russ Housley: Comment [2011-12-14]:
      The Gen-ART Review by Wassim Haddad on 13-Dec-2011 raised one
      editorial comment.  Please consider it:
    
      - In Security considerations section: s/maybe/may be/
  4. Pete Resnick: Comment [2011-12-13]:
    I am left wondering why this document is being published in the IETF instead of
    elsewhere and then later referred to by a GMPLS document that will use this
    terminology and framework, but I can say that I do not have a clue about the
    technology and am therefore deferring to others to review the content of this
    document.
  5. Dan Romascanu: Comment [2011-11-01]:
    Bert  Wijnen made the following comment (that I support) in his OPS-DIR review: 
    
    As the document writeup states:
    
       This document is an informational framework with nothing to implement.
       There are a number of drafts being progressed that address various
       aspects of the framework.
    
    So it would be those documents being progressed that would have to include any
    discussion about operational or manageability aspects of the various solutions.
    
    At the other hand, it might have been useful if this document would have touched
    upon some operational/manageability aspects for each of the possible solutions.
    It seems clear that there are different characteristics depending on which
    solution is chosen. Specifically the talk about "black links" makes me worried
    that solutions can become complex and less interoperable.
  6. Sean Turner: Comment [2011-12-13]:
    s6/s8: Need add a reference to [RFC5920].

draft-ietf-ppsp-problem-statement

  1. Jari Arkko: Discuss [2011-12-15]:
        I do, of course, support the development of a P2P streaming protocol, and I
    think it will be good for the industry. It is good to write a document that
    provides some justification and background for this.
    
    However, I do agree with others who have commented that the document overdoes
    this a little bit. A shorter and more matter-of-fact style would have worked
    better on me.
    
    But that is not my Discuss comment, I also have a more specific technical
    concern. Section 3.1 makes it sound like to deploy P2P caches an ISP needs to
    implement DPI-based detection of P2P content. I think that is first of all
    wrong, as adding the ISP as a participant in the particular trackers and P2P
    networks offers a much cleaner way to do this. Secondly, I do not think the IETF
    should condone or recommend DPI-based hidden caching.
    
    This does not change the fact that I agree with the general point of Section 3.1
    that a standardized method will be easier to implement, even when you do the
    implementation in the correct way.
    
    I suggest deleting some of the text from Section 3.1. that deals with the
    specifics of how the ISP deals with participation in a P2P network; those
    details are unnecessary for the general point to be made. 
        
  2. Stewart Bryant: Discuss [2011-12-12]:
        There is a fine line between providing evidence for a case to design something
    and delivering a commercial message. Unfortunately, even though the author does
    not appear to work for the companies mentioned the introduction sounds like a
    commercial. Additionally later in the document there is reference to at least
    one other company.
    
    Please will the author look at each mention of a company name and re-write the
    text to provide the evidence in a more objective, vendor neutral, style. 
        
  3. Adrian Farrel: Discuss [2011-12-13]:
        As it stands, I'm affraid I don't see much value in this document.
    Although it is probably harmless and the usecases may provide
    valuable background, a lot of the document is a discussion around
    the topic and does not give the WG any guidance or instructions.
    
    I think most of the "justification" in the Introduction is not really
    needed. Since the WG has been chartered, it is not necessary to go into
    great detail on your motivation. You could lift a few lines from the
    WG charter, and then use the paragraphs that say what this document 
    does. 
    
    Similarly, section 3 provides motivation for a standard PPSP, but the
    existence of the WG is plenty good enough orivation for the work. What
    seems to be missng, however, is the problem statement that says what
    the PPSP actually has to do. In other words, I find the document
    strangely without guidance to the developers of a standard PPSP.
    
    Fixing this might be particularly hard because there is no bug fix
    and no easy textual addition. Maybe I should phrase the question as
    "why does the WG see this document as a valuable addition to the canon?" 
        
  4. Adrian Farrel: Comment [2011-12-13]:
    I like that "chunk" is a unit of "block" with sub-unit "piece". What
    is "block"? :-)
    
    ---
    
    The definition of CDN in section 2 actually only provides a definition
    of "CDN node".
    
    ---
    
    "key signaling protocol" may be unfortunate term because it is used
    in other context to indicate a protocol that is used to signal "keys"
  5. Stephen Farrell: Discuss [2011-12-14]:
        (Discuss discuss, for the IESG really I guess) 
    How does this all fit with decade and cdni?  Are we heading towards a good 
    or bad outcome with all those?  An example of a bad outcome would 
    be 3 ways to do one thing that are incompatible but the same except for 
    gratuitous differences. Maybe I'm just missing some context but something 
    seems wrong somewhere...
    
    (And one for the authors/chairs...)
    - I don't see what PPSP WG document will include "considerations on
    threats and mitigations when combining both protocols in an
    application." That's the kind of thing that gets forgotten and where
    protocol specification authors will say "that's not my problem."
    What's the plan for addressing that in the WG?
     
        
  6. Stephen Farrell: Comment [2011-12-14]:
    - Section 4 says that you can have pull, push or a hybrid but does
    say if the PPSP wg is going to work on all of those or some of
    those. (Its sort of implied that all will be done via different
    "modes" but that's not clearly stated.) Since it'd be better to only
    have one "mode," I think the document should justify choosing to do
    all "modes." (If that's really what the PPSP WG are planning. If not
    then the document should say what the WG is actually planning.)
    
    - Section 5 really needs to say what sections 5.x are.  They could
    be use-cases the WG is going to tackle, or maybe the WG will decide
    later, or whatever is the case. Without that, its hard to know why
    sections 5.x are present.
    
    - 5.1: "easily expand the broadcasting scale" just seems wrong.  Is
    that sales-pitch (in which case delete it) or do you mean something
    else? 
    
    - Section 6 should mention that a malicious (or careless)
    peer/tracker can leak private information about other peers or
    trackers. 
    
  7. David Harrington: Discuss [2011-12-14]:
        1) in section 4, there is a discussion of pull-based versus push-based. The
    discussion talks about the benefits of pull-based (but not the drawbacks) and
    the fact that most systems use this approach. Then the push-based approach,
    which few deployed systems use, is discussed including the drawbacks but not
    much about the benefits. Then the conclusion is that a hybrid system woudl be
    best, with little justification for why hybrid i smore practical, and no
    discussion of whether anybody actually does this now.
    
    2) This document is supposed to be a problem statement, but throughout it the
    design of the proposed PPSP protocol is thron in. This document should focus on
    identifying what the problems are that need to be solved. Basically, this should
    discuss what problems the tracker and peer protocols each must address. This
    document seems to lump the tracker and peer protocols together as the PPSP
    protocol, and doesn't differentiate or clearly describe the problems that need
    to be solved by each protocol.
    
    I recommend dropping the notion of a PPSP protocol suite, which seems to
    encourage marketing of PPSP, and blurring of the distinction between the two
    protocols. This document should focus on describing the problems to be addressed
    by each of the two protocols: 
    "The tracker protocol handles the initial and
    periodic exchange of meta
    information between trackers and peers, such as peer
    lists and content
    information." - what are the problems that a tracker protocol
    addresses, and what problems must be overcome in its design? 
    "The peer protocol
    controls the advertising and exchange of media data availability between the
    peers." - what are the problems that the peer protocol addresses, and what
    problems must be overcome in tis design?
    
    in 5.3, there is an incomplete sentence.
    in 5.3, "a mobile peer within a high-
    load base station is unlikely to be selected, which may lead to higher load on
    the base station." is unclear. Does this mean "a mobile peer within a high-load
    base station is unlikely to be selected, because selecting the mobile peer might
    lead to higher load on the base station."?
    
    Discussion of the PPSP working group should be removed form the document. The
    goals and deliverables of the WG are documented in the charter, which will have
    a similar lifetime as the WG. This document published as an RFC will exist long
    after the WG has been closed. 
        
  8. Russ Housley: Comment [2011-12-12]:
      Please consider the comments provided in the Gen-ART Review by
      Francis Dupont on 24-Nov-2011.  The review can be found here:
      http://www.ietf.org/mail-archive/web/gen-art/current/msg06935.html
  9. Dan Romascanu: Comment [2011-12-15]:
    I find the document useful in intent but problematic in the way it is written,
    and I beleive that some of the sections need serious editing before publication.
    As the critical issues are covered in DISCUSSes of other ADs I will enter them
    as COMMENT:
    
    1. Section 1 needs to be shortened and all 'commercial' content needs to be
    dropped. The main functions should be described avoiding the mentioning of the
    vendors names.
    
    2. The requirements from the tracker and peer protocols need to be sumarized and
    listed in one place. I found the figures in section 5 quite useful to understand
    the functions, but it took time and effort to go through them as they are
    disparated in the descriptions of the use cases
    
    3. Avoid text (like in the Abstract) that may be interpreted as the protocol
    proposal is included in this document
  10. Peter Saint-Andre: Comment [2011-12-05]:
    The first three paragraphs of the Introduction are mostly marketing and deserve
    to be deleted.
    
    "In this document we propose an open P2P Streaming Protocol..." I think you mean
    "propose the development of" because this document does not define such a
    protocol.
    
    Section 3.3, paragraph 1: these numbers will become stale quickly. I suggest
    removing this paragraph.
  11. Robert Sparks: Comment [2011-12-13]:
    It's not obvious how this document is going to help the working group with it's
    protocol work, or help document the work once it's complete. Is the set of use
    cases intended to be a set of motivating examples, or does it exhaustively cover
    every scenario the protocol is expected to handle? Please consider clarifying
    those points.

draft-ietf-v6ops-happy-eyeballs

  1. Stewart Bryant: Comment [2011-11-28]:
    Wes raises an interesting point, the draft needs to discuss connectionless
    transport protocols.
  2. Wesley Eddy: Comment [2011-12-14]:
    
        
  3. Adrian Farrel: Comment [2011-12-11]:
    I understand why improving IPv6 experience in dual stack deployments is
    valuable to the IETF in promoting migration to IPv6. For that reason, 
    publication of this document may be beneficial and encourage 
    implementations to include more flexible selection algorithms such as 
    that described in this document. However, I don't see anything in this
    document that impacts interworking, so I don't see why it is Standards
    Track.
  4. Stephen Farrell: Comment [2011-12-09]:
    
        
  5. David Harrington: Comment [2011-12-14]:
    I've cleared
  6. Pete Resnick: Comment [2011-12-11]:
    I really think this document should have had a co-author in the apps area. It is
    written exceedingly "thinly" and doesn't really understand some of the
    application implementation issues. That said, I still think it is valuable and
    worth publishing (and hopefully updating in the future). Though it is a bit this
    for the standards track as it is now, I see the potential to fill this in over
    time with more proscriptive information, and therefore I don't object to go it
    going on the standards track now in anticipation of that. Some issues to
    consider for this go-round:
    
    3.1 - This has nothing to do with URIs. It is about hostnames. Hostnames used
    that don't appear in URIs have exactly the same issues.
    
    4. - Though using SYN and ACK in the diagram is fine, I recommend using words
    like "connection attempt" in the descriptive text. SYN and ACK are probably not
    as familiar to application layer folks, and since this is aimed at them, it is
    likely better to use the application layer terminology. Furthermore, there is a
    performance/resource impact to making a "connection attempt" that an apps person
    will understand that they might not if it is understood as only an additional
    packet.
    
    I agree with Stephen's concerns regarding "MUST cache". There are valid reasons
    to try v6 later even if v4 succeeds first, but those reasons must be carefully
    considered and understood. That sounds like a SHOULD.
    
    4.1 - The first few paragraphs strike me as introductory material, not part of
    the alogirthm requirements.
    
    4.2. - "SHOULD do so every 10 minutes" I think instead you mean "SHOULD do so no
    more frequently than every 10 minutes". It's perfectly fine to do so every 20
    minutes, or once a day.
    
    4.3. - DNA does not describe how applications (which are the ones who are going
    to implement Happy Eyeballs) are to be notified of these changes. Though I agree
    that a Happy Eyeballs app should be able to ask its host to do a DNA for it (or
    more to the point, get notifications from the host), that's an additional
    requirement on these apps and should be noted.
  7. Peter Saint-Andre: Discuss [2011-12-08]:
        The Apps Directorate review by Murray Kucherawy on 2011-11-26 raised two major
    technical issues and eight minor technical issues. These issues merit a
    response. The review can be found here:
    
    http://www.ietf.org/mail-archive/web/apps-discuss/current/msg03819.html 
        
  8. Peter Saint-Andre: Comment [2011-12-08]:
    Much as I love XMPP, I would change "xmpp clients" to "IM clients".
  9. Sean Turner: Comment [2011-12-14]:
    Please consider the editorial comments suggested by Sandy in here secdir review:
    
    http://www.ietf.org/mail-archive/web/secdir/current/msg03016.html

draft-gerhards-syslog-plain-tcp

  1. Adrian Farrel: Comment [2011-12-11]:
    It would be good if the Introduction included a brief paragraph on the
    purpose/content of this document. The first paragraph of Section 4
    contains roughly the necessary material.
    
    ---
    
    I am uncomfortable (but not quite to the point of a Discuss) by the way
    that this I-D flies in the face of IETF consensus to recommend the use
    of TLS. I believe this could be resolved by a slightly stronger 
    statement on the intent of the document to facilitate interoperability
    with legacy deployments whild continuing to recommend the use of TLS.
    I.e. "this document does not recommend that new implementations or
    deployments use syslog over TCP except for the explicit purpose of 
    interoperating with existing deployments."
    
    ---
    
    I am surprised that section 5 does not mention TCP/AO.
  2. Stephen Farrell: Comment [2011-12-14]:
    - I agree with Dave's discuss points 1,2 and 4 and sympathise with
    his point 3.
    
    - Be nice to add the hex values that go with %d32 and %d126 just to
    be super-clear
    
    - 3.1 mentions "relays" but those weren't mentioned in the intro -
    be nice to say what those are in section 1.
    
    - What does "not available" mean at the end of section 5?  I think
    it would be better to say "This protocol SHOULD NOT be used unless
    syslog/tls [RFC5425] has been tried and failed, e.g. because there
    is no listener on port 6514."
    
    - I think you could note that falling back to this if syslog/tls
    fails could in principle indicate that an attack is happening. If
    there's a sensible action to take there (e.g. some local logging of
    the failure of the TLS handshake or whatever in addition to remote
    logging using this) that'd maybe be worth saying.
    
    
  3. David Harrington: Discuss [2011-12-13]:
        
    As co-chair of syslog WG, I have worked witrh Rainer and Chris closely, and
    understand that they feel this is valuiable documentation for the community. I
    disagree for a number of reasons.
    
    1. I think the applicability statement is not consistent with IETF consensus:
    "It is hoped that this description, along with the assignment of a standardized
    port for this protocol, will promote future interoperability."
    IETF consensus is
    to use strong security [RFC3365 - BCP61] to provide secure interoperability.
    RFC5424 and RFC5425 have IETF consensus as the right way to achieve syslog
    interoperability, and to do so securely.  Based on BCP61, RFC5424 and RFC5425
    provide mandatory-to-implement security features, which may be configured by
    operators to provide no security if operators so choose (RFC5425, section 5).
    I
    do not believe this document will result in future interoperability for syslog,
    and sends the wrong message to the community about how to achieve
    interoperability. I do not believe it is in the IETF interest to assign a
    standard port number for syslog/tcp.
    
    2. I believe this document, if published, should be published as Historic (or
    Obsoleted by RFCs 5424 and 5425).
     I believe this designation is important based
    on experience with RFC3164, which allegedly documented BSD Syslog, but actually
    ended up being a survey of existing syslog/UDP implementations that showed how
    on-the-wire formats of the many existing implementations had little in common.
    Most only had the first byte in common. Many vendors claimed "compliance" to
    RFC3164.
    I believe this document needs to have it very clearly spelled out that
    this is only a document of past practices, is NOT an IETF standard, and should
    NOT be implemented in new implementations.
    
    RFC3164 (legacy syslog/udp) was obsoleted by RFC5424. This legacy syslog/tcp
    document should be handled the same way.
    
    3. Personally, I don't see a lot of value to this document.  Similar to existing
    implementations of syslog that run over udp, existing implementations of syslog
    that run over tcp are not very consistent. 
    This document does not contain
    enough detail for syslog receivers/applications to process incoming legacy
    messages; application implementers would need to do additional research into the
    formats used by specific implementations. Therefore, this document does not
    serve to significantly improve interoperability between senders and receivers.
    Cross-vendor interoperability could be improved by standardizing a port#, and
    recommending consistent implementation choices, such as message layout, support
    for octet-counting versus framing in the message format, internationalized
    character sets, and transport session initiation and closure. 
    The IETF has
    already standardized support for a message layout, and internationalized
    character sets in RFC5424.
    The IETF has already standardized a transport for
    syslog messages in RFC5425, including session initiation and closure, a standard
    port#, as well as strong security as called for by BCP61.
    I have concerns that
    publishing this as an RFC sends the wrong message to the community,  and am
    especially concerned that vendors wil use this to claim "compliance" to an IETF
    RFC,  just as they did with RFC3164.
    This could slow vendors moving to support
    interoperability by using the IETF standards defined in RFC5424 and RFC 5425.
    
    4.  Despite my belief that publishing this document will not make the Internet
    run better, I could accept publication of this document with a Historic or
    Obsolete label and a big IESG Note that says
    
    "The IESG does NOT RECOMMEND implementing or deploying syslog over plain tcp,
    which is documented in this document, because it lacks the ability to enable
    strong security [BCP61].
    
    syslog/tls [RFC5425] is RECOMMENDED for implementation so that security features
    are available to operators who want to deploy secure syslog, and those security
    features can be turned off for those who do not want them." 
        
  4. Pete Resnick: Comment [2011-12-13]:
    I must agree with Robert's comment that the port allocation seems inappropriate.
    However, it concerns me that the port that is chosen some of the time is the rsh
    port. If there is an unregistered port that is widely used for this, it should
    be registered.
    
    I agree with Adrian's comment that some of the contents of section 4 would be
    terribly helpful in the intro.
    
    I think Peter's comment regarding character terminology is important, and I'm
    happy to see you're addressing it.
    
    I am ambivalent as to whether the document should be Informational or Historic.
    I lean slightly toward Informational since it is describing widespread current
    practice.
    
    [Updated to add:]
    
    Please re-use ABNF constructs defined in RFC 5234 instead of redefining them
    here:
    
    3.4.1 - DIGIT and SP are already defined in 5234.
    
    3.4.2 - LF is already in 5234.
    
  5. Peter Saint-Andre: Comment [2011-12-08]:
    According to BCP 166 (RFC 6365):
    
       The terms "charset", or "character encoding scheme"
       and "coded character set", are strongly preferred over the term
       "character set" because "character set" has other definitions in
       other contexts, particularly outside the IETF.
    
    Please consider changing the term used in Section 3.1 of this I-D to match BCP
    166.
  6. Robert Sparks: Discuss [2011-12-13]:
        Capturing a description of what's observable in the wild is a very good thing -
    thank you for putting this document together. If that's all this document is
    trying to do, why isn't it Historic, and why doesn't it register the port(s)
    that
    existing implementations are actually using?
    
    A new port for something that's not a standard (and is not already the de facto
    port)
    doesn't seem like the right thing to do.
    
        
  7. Robert Sparks: Comment [2011-12-13]:
    Most of the document is written with a tone of "here's what we see deployed
    already",
    which is good. In a few places it drifts into a tone that would be
    more appropriate
    for "and we want people to make more things that do this".
    Section 3.2, in particular,
    reads more like a protocol definition than a
    description of already existing behavior.
    Section 3.4 uses the phrase "usually
    preferred". Something like "has caused fewer
    problems" would be more descriptive
    (if it's accurate).
  8. Sean Turner: Comment [2011-12-14]:
    I tend to agree with Dave here.

draft-oreirdan-mody-bot-remediation

  1. Jari Arkko: Comment [2011-12-15]:
    Thanks for writing this.
  2. Ron Bonica: Comment [2011-12-14]:
    Minor comments:
    
    Section 1.3 - Do we really need to define the word host
    
    Section 1.5 - When IPv6 takes off, you will see fast-flux using AAAA records
    
  3. Stewart Bryant: Comment [2011-11-28]:
    There is the outstanding issue of verifying that the IPR issues noted by the
    Shepherd have been fully resolved. I am sure that Stephen will verify the
    resolution before issuing a publication request, and thus am highlighting this
    issue as a comment.
    
    =====
    
    "An ISP may use Netflow [RFC3954]"
    
    I would think that the the standards based solution  IPFIX [RFC5101] would be a
    better reference.
    
    =====
  4. Wesley Eddy: Comment [2011-11-29]:
    This is a good document.  I am not at all an expert in this area, but my only
    comment is that it seems like there may be some liability to the ISP in
    attempting to detect bot infections because they may then need to bear the
    burden to report criminal activity that they witness.  I'm sure commercial ISPs
    have considered this in their policies, but I didn't notice it clearly mentioned
    in the document.
  5. Adrian Farrel: Comment [2011-12-12]:
    Thanks for a very readable document with a lot of valuable information.
    
    I have a few small conversation topics that I would appreciate you
    thinking about and addressing if you can see a way forward.
    
    ---
    
    I am surprised by the statement in the Abtract that a user with an
    infected computer is exposed to the risk of phishing. Te seond statement
    that their computer might be used as an inadvertent participant in a
    phishing network sounds more reasonable.
    
    ---
    
    I wonder whether Section 5 needs to consider the risks of notifications
    after false positives, and the problems caused by false notifications
    as a form of attack.
    
    ---
    
    Section 7 upset me a little. Recognising the need of ISPs to protect 
    their businesses, I also see the need to continue to provide servie to
    vulnerable people who cannot be expected to protect their computers.
    
    In view of this, you might discuss the service providers' duty to ensure
    that hosts connected to their network cannot become infected with bots
    through data transfered across the service providers' networks. Or you 
    might just drop the text about account termination.
    
  6. Pete Resnick: Comment [2011-12-13]:
    1.1 - I have never heard of "benign bots" before. Is this an invention of the
    authors or is it used in some circles? I would prefer if the document referred
    to only the malicious applications as "bots" and referred to the benign
    applications as "background applications" or "daemons" or "background
    processes". I think it is still important to point out that such applications
    should not be monitored for or prevented from functioning.
    
    1.2 - "Bot Networks or Botnets" is better defined as "a group of bots that are
    remotely controlled by a single party". The first sentence of 1.2 is circular.
    
    I know what all of those malicious activities are, but it might be useful to
    define some of them.
    
    "Infection vectors" is undefined. So are a bunch of the terms in that paragraph.
    
    Much of this section assumes a familiarity by the reader. If the reader was this
    familiar with the material, this section wouldn't be necessary. Similarly with
    1.4.
    
    1.5 - The information in the two paragraphs is reversed, burying the important
    point: Compromised hosts are used as proxies to web servers in order to hide the
    IP address of the server itself. This is *accomplished* by DNS Fast Fluxing.
    
    10. - Some of the activities outlined in section 3 should be called out
    specifically with regard to privacy considerations.
    
    A reference to RFC 4948 seems pretty essential. I'm surprised not to see some of
    the information that appears in that document in this one.
  7. Dan Romascanu: Comment [2011-12-15]:
    Good document. All my comments are related to Section 5: 
    
    1. 
    
    > It should be possible for the end user to indicate the preferred
       means of notification on an opt-in basis for that notification
       method.  It is recommended that the end user should not be allowed to
       totally opt out of notification entirely.
    
    It looks like either 'totally' or 'entirely' is redundant
    
    2. I would expect notifications by management protocols like SNMP and NETCONF be
    also described in this section
    
    3. The danger of DoS attacks by flasely reporting of bots via notifications
    shoulsd also be mentioned as a major security concern
  8. Peter Saint-Andre: Comment [2011-11-29]:
    Overall this is a helpful document. I have a few comments and suggestions.
    
    In Section 1.2:
    
    OLD
       The detection and
       destruction of bots is an ongoing issue and also a constant battle
       between the Internet security community, network security engineers
       and bot developers.
    
    NEW
       The detection and
       destruction of bots is an ongoing issue and also a constant battle
       between the Internet security community and network security 
       engineers on the one hand and bot developers on the other.
    
    P2P is not a communication protocol, it is an architectural approach.
    
    It is a bit odd to speak of the "introduction" of HTTP, given that HTTP was
    invented over 20 years ago.
    
    The document sometimes conflates bots and botnets. For example:
    
       As a consequence, botnets that are initially detected
       and classified by the ISP as one particular type of bot need to be
       continuously monitored and tracked in order to identify correctly the
       threat the botnet poses at any particular point in time.
    
    Although a botnet consists of bots, not all bots are part of a botnet (and we
    certainly can't say that a botnet can be classified as a type of bot, as in the
    quoted paragraph).

draft-mckenzie-arpanet-host-host-protocol

  1. (none)