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

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. 
    
  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)