IESG Narrative Minutes

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

Narrative scribe: Barry Leiba and Susan Hares (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. Sieve Email Filtering: Include Extension (Proposed Standard)
    draft-ietf-sieve-include-4
    Token: Pete Resnick
    Note: Barry Leiba (barryleiba@computer.org) is the document shepherd.
    Discusses/comments (from ballot 3680):
    1. Jari Arkko: Discuss [2012-01-04]:
      I spent some time thinking about whether I want to say something or not.
      But I'll join others in worrying about the issue of recursion, but raise some of the comments to a level of a Discuss.
      I should also say that developing a programming language is difficult, particularly when you add tiny features one at a time (like subroutines). For instance, the recursion discussion is difficult because you've conflated the concepts of module references and actual invocations of those modules during execution time.
      It might have been better to think about an upgrade of the sieve model in a more architectural manner. Or maybe the WG already did and I am just not aware of it. In any case, this is just a comment and not a part of my Discuss.
      The Discuss is the following. First, as Adrian noted you must define what you mean by recursion, because otherwise implementations are likely to miss that they need to track indirect inclusions as well: A includes B, B includes A. I wonder if it would have been easier just to have the concept of nesting levels and maxing out on them. That's how I would implement this if I was implementing it. No need to track recursion in specific ways.
      Second, I think your minimum requirement of three levels is a bit too small. If people actually start using this they are likely to engineer script structures that need more, and if not all implementations support that number of levels there will be breakage. I'd say five or ten would be a more reasonable minimum level. But I'm not asking you to put any specific number but rather I'm asking you think about this and make a rational decision based on some basis. (And again, maybe you already have and you just need to tell me what the basis of that decision was.)
      I also think that the active/other script definition for checking recursion is broken, but that was already raised by Russ' Discuss.
    2. Adrian Farrel: Comment [2012-01-02]:
      I think it would be helpful if you spent more time explaining what you mean by recursion. Direct recursion is (of course) a lot easier to spot than general (by menas of indeirections) recursion. But it is the general case you need to protect against and that is potentially considerably more complicated for an implementation to police. Since the consequences are just as bad, and since it may be harder for the coder to realise that they have transgressed, I think you should call it out explicitly.
      Perhaps add a definition of recurssion to Section 2, and then note the implication for tracking all nested script names in 3.1
    3. Stephen Farrell: Comment [2011-12-30]:
      Is SIEVE turning into a fully-fledged programming language? I guess I wonder if that's happening by design or by accident. (Not that I know which would be better;-)
    4. Russ Housley: Discuss [2011-12-31]:
      The Gen-ART Review by Reviewer: Ben Campbell on 13-Dec-2011 raises some points, the authors have responded to them, but the discussion has not completed yet. I believe the document needs to be updated to at least address Ben's first point:
      -- section 3.1, paragraph 4: "Implementations MUST NOT generate errors for recursive inclusions at upload time, as this would force an upload ordering requirement upon script authors / generators. However, if an active script is replaced with a faulty script and would remain the active script, an error MUST be generated and the upload MUST fail."
      These two statements seem contradictory on a quick reading. In particular, how can the latter assertion avoid an upload ordering requirement? Or do you mean faulty in some way other than being recursive?
      If you're replacing an active script, it has to be correct all the time, and uploads are atomic only on a per-script basis. There's a risk that if you're uploading a set of scripts that include one another, at some intermediate stage while some scripts are uploaded but not others, they are in an invalid state. The managesieve spec says that scripts must be validated at upload time. The language above is trying to say that you can upload all of the scripts that may include one another in any order without generating errors immediately, however, if you're replacing an active script or a script included by the active script, then you DO have to upload a correct script right from the get-go.
      Is this just a question of whether the script(s) are replacing active scripts? That is, the license to create a transient invalid state is suspended if if you are replacing an active script? If so, how would one go about updating a set of linked scripts when one or more of them replace active scripts? Should one somehow deactivate the old ones, load all the scripts, then activate them?
    5. Peter Saint-Andre: Comment [2012-01-04]:
      Section 3.1 states: "An error MUST be generated when such a script is executed."
      However, Section 3.2 states: "Implementations MUST NOT generate an error if an "include :once" command names a script whose inclusion would be recursive; in this case, the script MUST be considered previously included and therefore "include :once" will not include it again."
      These two are in conflict. I suggest changing the text in Section 3.1 as follows: "An error MUST be generated when such a script is executed, except as noted under Section 3.2."
      In Section 3.2: "The ":optional" parameter indicates that the script may be missing."
      I'd change "may" to "MAY" or (to avoid confusion with "might be missing") say "is allowed to be absent" or somesuch.
      Section 3.4.1 states: "If a "global" command is given the name of a variable that has previously been defined in the immediate script with "set", an error MUST be generated either when the script is uploaded or at execution time."
      Does that impose an ordering requirement on script uploads?
    6. Sean Turner: Comment [2012-01-01]:
      1) s3.2: Contains the following:
      "The "include" command takes an optional "location" parameter, an optional ":once" parameter, an optional ":optional" parameter, and a single string argument representing the name of the script to include for processing at that point."
      Shouldn't the "optional"s be "OPTIONAL" to ensure they match they ABNF?
      2) s3.2: Contains the following:
      "Note: It is RECOMMENDED that script authors / generators use the ":once" parameter only when including a script that performs general duties such as declaring global variables and making sanity checks of the environment."
      Can you rephrase this so the requirement isn't in a "note"?

    Telechat:

  2. Neighbor Discovery Optimization for Low Power and Lossy Networks (6LoWPAN) (Proposed Standard)
    draft-ietf-6lowpan-nd-18
    Token: Ralph Droms
    Note: Carsten Bormann (cabo@tzi.org) is the document shepherd.
    Discusses/comments (from ballot 4015):
    1. Stewart Bryant: Comment [2012-01-05]:
      I agree with the points that Adrian makes.
    2. Adrian Farrel: Discuss [2012-01-03]:
      I have added a placeholder to this Discuss to ensure that Pascal Thubert's last call comments are resolved (one way or the other).
      This is a really small Discuss and easily fixed. The way that [I-D.ietf-6lowpan-hc] is used in Sections 1.4 and 3 make it a normative reference.
      Section 3.4 seems to contain a lot of options and sub-options with the over-arching assumption that "all 6LRs in a network are configured to perform these functions homogeneously." This seems like a lot of configuration complexity for very simple nodes in an environment where users will not be sophisticated. Moreover, it seems highly likely to me that misconfigurations will arise and homogeneity will be lost.
      The latter suggests that the assumption of homogeneity cannot be trusted. You will need to handle (at least at the level of fault detection) mixed mode configuration.
      The former suggests that you should have some form of automatic arbitration (i.e., something more sophisticated than fault detection) so that the network can become homogeneous across the sub-options.
      Table 1 in Section 4.1 demands an IANA action. In Section 12 there is a brief statement:
      "This document also requests IANA to create a new registry for the Status values of the Address Registration Option."
      This text needs to be beefed up to show:
      - which is the owning registry
      - what the name of the sub-registry should be
      - either a pointer to section 4.1 or (preferably) all of the relevant information
      Section 6.1: "A router SHOULD NOT send Redirect messages in a route-over topology, but MAY send Redirect messages in a mesh-under topology."
      The use of 2119 language here may be correct, but leaves some holes.
      In route-over, under what conditions MAY a router send Redirect messages?
      In mesh-under, what is the normal behavior? Presumably "SHOULD NOT". But why MAY a Redirect be sent in mesh-under?
      Section 12
      Please remove the following text from the I-D before advancing it to the RFC Editor
      "For the purpose of protocol interoperability testing of this specification, the following values are being used temporarily:
      "o TBD1 = 31
      "o TBD2 = 32
      "o TBD3 = 33
      "o TBD4 = 155 XXX
      "o TBD3 = 156 XXX"
      (There is, in any case, a typo s/TBD3/TBD5/ on the last line)
      Section 8.2.1: "A node MUST silently discard any received Duplicate Address Request and Confirmation messages that do not satisfy all of the following validity checks:"
      I suspect you mean "...message that does not satisfy any of the following..." Since you have written that only the messages that fail every one of the checks must be discarded.
    3. Adrian Farrel: Comment [2011-12-31]:
      A strict reading of one sentence in the Abstract may be misleading...
      "The traditional IPv6 link concept and heavy use of multicast make the protocol inefficient and sometimes impractical in a low power and lossy network."
      This reads as though it is IPv6 that is inefficient/impractical. Maybe
      NEW: "The traditional IPv6 link concept and heavy use of multicast make the Neighbor Discovery protocol inefficient and sometimes impractical in a low power and lossy network." END
      "LoWPAN" is not yet in the RFC Editor's registry of "well-known" acronyms indicated by an asterix at http://www.rfc-editor.org/rfc-style-guide/abbrev.expansion.txt (Actually, it is not on that page at all!)
      You may want to encourage your AD to lobby for it to be added. In the meantime, please expand it on first use (by adding it in the first sentence of the Abstract, and by expanding it in the second sentence of the Introduction).
      A reference to a wider and more detailed definition of a 6LoWPAN might also be helpful.
      The language in section 1.2 describing the differences between mesh-under and route-over introduces some ambiguity by slightly careless use of language. The problem arises from trying to distinguish between routing (at the IP layer) and link-layer routing. Similarly by saying that in mesh-under all "hosts" are on the same link, yet that forwarding is handled by a link-layer mesh routing protocol.
      I don't think there is anything here that is unusual to people familiar with layered networking. You might make the text crystal clear by explaining the existence of layers and then refering always to "links in the IP layer" and "routing in the Ethernet layer".
      While a lot of my gripe is my own sensitivity to mesh-under being proposed for environments where IP routing is more appropriate, I do think you may add value to the document by some clarification in this section.
      Similarly, a little more tightness in Section 2 might help. For example, a 6LR is defined as a router in a 6LoWPAN that can communicate with another router in the 6LoWPAN. This doesn't really say very much. What is routed? What is the ocnnectivity between the 6LRs?
      (By the way, I am not sure that the term "host" adds any clarity. For example...
      "In both types of configurations, hosts do not take part in routing and forwarding packets and they act as simple IPv6 hosts."
      ...where you say that a host acts as a host!)
      Section 1.3 uses RFC 2119 language before the boilerplate is introduced in Section 2.
      Two of the bullets in Section 1.4 appear to have a minor contradiction. Viz.
      "o A 6LoWPAN is configured to share one or more global IPv6 address prefixes to enable hosts to move between routers in the 6LoWPAN without changing their IPv6 addresses."
      "o Since the 6LoWPAN shares one single prefix throughout the network, mobility of nodes within the LoWPAN is transparent. Inter-LoWPAN mobility is out-of-scope of this document."
      "one or more...prefixes" vs. "one single prefix"
      The bit numbering on the figure in Section 4.4. is misaligned.
      Should the timers and thresholds in Section 5.3 be configurable?
      Which of the constants in Section 9 needs to be configurable?
      Should Section 5.3 have a forward-pointer to Section 9?
      Section 6.2 is woolly for a specification.
      "More or less" ?
      "might want to" ?
      Several times (e.g. 6.5.5, and particularly Section 8) you say "optionally". You might want to consider using RFC 2119 language.
      Section 11 talks of rejecting DAC and DAR messages in some potential security violations. Do you mean "reject" or "discard"?
      I think Section 13 is a fine idea. However, the only text in the Section says...
      "This section discusses a guideline of new features for implementation and deployment."
      Would it be possible to add a little more interprettation of the tables?
      By the way, I find my interpretation of the tables give rise to a few questions...
      If a feature is marked as "SHOULD" deploy, how would that be possible unless implementations "MUST" implement?
      If a feature "MUST NOT" be deployed, does it matter whether the implementation includes the option?
    4. Stephen Farrell: Discuss [2012-01-02]:
      #1 1.4 - "it is assumed that 6LRs register with all the 6LBRs." is ambiguous - does it mean each 6LR registers with some 6LBR or s/each/all/ or s/some/all/ or both? Assuming that all 6LRs are registered with all 6LBRs would seem to be too difficult and unwise so I think this needs fixing.
      #2 1.4 - Why would probabilistic uniqueness of non-EUI-64-derived addresses not be sufficient in some networks? If it is, then the "must be either assigned or checked" seems wrong.
      #3 3.2 - Does this mean that if I can pretend to be a router I can force (some) nodes to change their addresses? If so, why is that not mentioned as an attack in the security considerations? (If IP-address based node reputation ever evolved for nodes like these then this would be serious attack - misbehave as addr1, pretend to be a DHCP server and then force addr1 on some other innocent node.)
      #4 3.3 - How long is a sleeping node expected to say awake when sending a registration message? Is that long enough to get an error saying its chosen address is in use already? If not, then what prevents that node constantly re-awakening and using the duplicate address (or many identical such nodes doing that all the time)? (Saying "A host retransmits...until..." later in that section isn't clear enough really - there's no 2119 language there at all so I don't know if that's a MUST or MAY.)
      #5 8.1.4 - Is the last sentence here really optional, (everything in section 8 should be optional, right?) or is that behaviour meant to apply to all cases? If the latter, it really ought be in 4.2 shouldn't it? Also there are two 6CO's mentioned there, but its not clear to me at what point the 2nd is sent (T+5 presumably?)
      #6 What does "expects" mean in the security considerations? (Section 11, 2nd para.) That's not 2119 language. Are you saying this protocol MUST NOT be used if layer 2 security isn't sufficiently strong or is missing? If not, then what?
      #7 How can "Using link-layer indication for NUD" be a SHOULD deploy but only a MAY implement? (Table 2, in section 13.)
    5. Stephen Farrell: Comment [2012-01-02]:
      General - The logic as to why mesh-under and route-over are the most important topologies is not explained here and I don't see why its most valuable to tackle this problem in a topology-specific manner. It's also a shame that 1.3 needs to have all nodes implementing this to get any benefit and that each node must be part of only one network. (The latter is particularly unfortunate given that sleeping node wake times might cause such a condition over time.) However, this is maybe not actually a problem since the protocol doesn't seem to be really specific to those topologies - is that right? If so, then I'd suggest weakening the language to say that e.g. the authors or WG are more interested in those topologies, but that the protocol might work in other contexts too.
      Various places: - What's a non-transitive wireless link?
      Abstract - is a bit awkwardly written, some polish could usefully be applied.
      1.1 - I don't get the relevance of the "primarily two types" of lowpan topology on p5. Only the last sentence of that paragraph seems relevant or necessary. Similarly with section 1.2 which, other than introducing terminology seems unnecessary.
      1.3 - A number of the goals say "optimize" - is that meant to mean "improve" or "make the best"? In the latter, case, that would seem to require more work, e.g. to be able to compare approaches via metrics or something. Since I don't think that's really needed, I'd say s/optimize/improve/g would be more correct. (Similarly for s/minimize/reduce/)
      1.4 - I don't know why the following assumption is needed: "A 6LoWPAN is configured to share one or more global IPv6 address prefixes to enable hosts to move between routers in the 6LoWPAN without changing their IPv6 addresses." Why is it necessary to say this? (The spec would be clearer if that were clear I think.)
      1.4 - please don't use the reference as part of the sentence "[I-D.ietf-6lowpan-hc]" being the one that stood out - surely that has a name?
      1.5 - I can't parse the first sentence.
      3.2 - s/required/REQUIRED/g? and is it clear what it means to "REQUIRE" something of a lowpan? (Rather than a node)
      3.3 - "suspects" seems too vague, suggest giving at least one precise (common) condition, and if necessary saying there may be others too
      3.3. "The registration can fail (an ARO option returned to the host with a non-zero Status)..." the parenthetic clause isn't clear there. Suggest splitting the sentence.
      3.4 - What's context dissemination? Maybe needs a forward ref?
      3.5 - How does packet loss impact on "successfully registers with"? (Just wondering.)
      4.3 - where is "sequence number arithmetic" defined?
      5.3 - What are "theses packets"? Maybe a way to get a few PhDs? That'd be nice:-)
      5.3 - Where is "binary exponential backoff" defined?
      5.4.3 - Where is the Default router lifetime defined?
      5.5.3 - What does "no more default routers" mean?
      5.8.1 - seems wrong to say a host should consider how quickly topology changes, how'd it know in general?
      6.2 - initialising an interface "more or less" like something is a vague for a spec.
      8.1.2 - "similarly" seems vague
      13 - The introductory text here is confusing - what's this section for really? Does "deploy" mean "use"? I'd prefer the latter term.
    6. Russ Housley: Comment [2011-12-31]:
      The Gen-ART Review by Richard Barnes on 30-Dec-2011 raised one suggestion. Please consider it:
      "The phrase "transitive link" is unfamiliar to me. A definition would be helpful."
    7. Peter Saint-Andre: Comment [2012-01-04]:
      Adrian Farrel expressed better than I could my concerns about the complexity of this technology, especially given the target environment.
      The phrase "IP-over-foo document" is a bit vague and breezy. Could you at least provide an example of such a document?

    Telechat:

  3. An uniform format for IPv6 extension headers (Proposed Standard)
    draft-ietf-6man-exthdr-05
    Token: Jari Arkko
    Note: Brian Haberman (brian@innovationslab.net) is the document shepherd.
    Discusses/comments (from ballot 4027):
    1. Ron Bonica: Comment [2012-01-02]:
      This document updates RFC 2460, but I will let Adrian hold that DISCUSS.
    2. Ralph Droms: Discuss [2012-01-03]:
      I agree with Adrian and Ron that this document updates RFC 2460.
      I also agree with Stephen that additional discussion is needed regarding how this document updates RFC 2460 regarding middlebox inspection of extension headers. That discussion might be as simple as "middleboxes perform extension header inspection today in contradiction of RFC 2460." The document needs to make the point explicitly so the IETF is aware of and can discuss whether or not to officially sanction such behavior.
    3. Wesley Eddy: Comment [2012-01-03]:
      Extension headers are sensitive to ordering, partial deployment, and other issues. I don't think the guidelines in this document mitigate these in a meaningful way (e.g. due to the fact that it remains unknown the intermediate nodes whether unrecognized extensions earlier in the chain should alter later extension header or upper layer protocol processing), HOWEVER, I don't think the guidelines are harmful either, and can see that it's desirable to have a recommended base extension header format.
      For some time, high-rate DPI that I have seen has used heuristics rather than actual protocol processing. I do not think adoption of the guidelines in this document will alter that, though "helping" such devices seems to be a goal for this work. It seems undesirable to me, in general, to restrict protocol formats in order to aid layer violations ... but in the case of this particular document, I believe no harm is done.
    4. Adrian Farrel: Discuss [2011-12-31]:
      Doesn't this update RFC 2460 such that the format of future extension headers is predictable?
    5. Stephen Farrell: Discuss [2011-12-30]:
      - RFC 2460 says that "a receiver must not scan through a packet looking for a particular kind of extension header and process that prior to processing all preceeding ones" (end of p6), whereas this is saying that we need a way to skip unknown extensions. Those seem to be in conflict. Does that matter? If not, then saying *why* not would be good. (Simply saying "we need DPI" doesn't answer this question IMO.) If that conflict does matter, then what's the resolution? I don't understand how resolving that conflict can be "future work" in any normal sense if that's what's meant by section 6.
    6. Stephen Farrell: Comment [2011-12-30]:
      - Doesn't this update rfc 2460?
    7. David Harrington: Comment [2011-12-28]:
      abstract: s/past/beyond/
      (past can also mean previous; the intro has more context for the usage)
      intro: s/absolutely essential in the Internet-Draft proposing the new option with hop-by-hop behavior./absolutely essential./
    8. Russ Housley: Comment [2011-12-31]:
      The Gen-ART Review by Kathleen Moriarty on 4-Dec-2011 suggested some editorial changes, and the author agreed to make them. However, the changes have not been made yet.
    9. Peter Saint-Andre: Comment [2012-01-04]:
      My colleagues have raised a well-rounded set of questions about this document. In addition, I think it could say more about the impact on interoperability and Internet operations (these issues are mentioned in the introduction but not described in detail).
    10. Sean Turner: Comment [2012-01-04]:
      1) s4: Contains the following:
      Next Header: 8-bit selector. Identifies the type of header immediately following the Extension header. Uses the same values as the IPv4 Protocol field.
      Don't you need a reference for the values? Maybe: [IANA_IP_PARAM] IANA, "IP Parameters", <http://www.iana.org/assignments/ip-parameters>.
      2) Where do I get a ticket for the "doesn't this update 2460" bandwagon?

    Telechat:

  4. IANA Registries for the RDDP (Remote Direct Data Placement) Protocols (Proposed Standard)
    draft-ietf-storm-rddp-registries-01
    Token: David Harrington
    Note: David Black (david.black@emc.com) is the document shepherd.
    Discusses/comments (from ballot 4034):
    1. Jari Arkko: Discuss [2012-01-04]:
      The draft has several places where it says: "Assignment policy: If the requested value is not already assigned, it may be assigned to the requester."
      This was a bit confusing because the allocation policy (e.g., Standards Action) came much later in the Section, and I was wondering if the above meant "FCFS".
      I would replace all of these with one statement at the beginning of Section 3:
      "Allocation requests for the below registries may come with a suggested numerical value that should be assigned. Such suggestions are useful when early implementations have already chosen particular code points before the final RFC comes out. If the allocation request in general is accepted, such suggestions may be honored if the suggested value is still free to be assigned."
      Or some words to the same effect.
    2. Jari Arkko: Comment [2012-01-04]:
      I agree with Pete that the RFC 2119 language is in general unnecessary.
      In some of the registries, providing an experimental value for testing and development purposes would be useful, IMHO. Look at RFC 5872 Sections 2.1 and 3 for an example and RFC 3692 for general guidance. For instance, I would reserve one RDMAP operation code value (0xF) as an experimental value. And 0xFFFF for SCTP Function Codes for DDP Session Control. But whether you want to make such a reservation depends of course entirely on your understanding of the needs of the RDDP community and how the protocols might evolve.
    3. Pete Resnick: Comment [2012-01-03]:
      I think the 2119 language is unnecessary and ought to be removed. Some of it belongs with the protocol that defines the field. Some of it is giving instructions to IANA about their processing, which seems an inappropriate use of 2119.

    Telechat:

2.1.2 Returning Items

  1. Virtual Subnet Selection Options for DHCPv4 and DHCPv6 (Proposed Standard)
    draft-ietf-dhc-vpn-option-14
    Token: Ralph Droms
    Note: John Jason Brzozowski (john_brzozowski@cable.comcast.com) is the document shepherd.
    IPR: Cisco's Statement of IPR related to draft-ietf-dhc-vpn-option-11
    Discusses/comments (from ballot 3218):
    1. Adrian Farrel: Comment [2012-01-04]:
      I still think that using the terms "relay-agent-information sub-option" and "relay sub-option" interchangeably adds confusion
    2. Stephen Farrell: Comment [2012-01-03]:
      - NVT ASCII could do with a reference.
      - Last sentence of section 5 is odd. (just before start of 5.1)
    3. David Harrington: Discuss [2012-01-03]:
      1. From section 5, "A relay agent which receives a DHCP request from a DHCP client on a VPN SHOULD include Virtual Subnet Selection information in the DHCP packet prior to forwarding the packet on to the DHCP server unless inhibited from doing so by configuration information or policy to the contrary." This reflects an implicit requirement; that requirement should be made explicit. - "DHCP relay agent implementations MUST provide a configuration knob to inhibit this behavior." (I'm not sure how you expect policy to be specified, but with the configuration knob, a policy might use the knob to enforce a policy.)
      2. In section 5.1, "In some cases, a DHCP server may use the Virtual Subnet Selection sub-option or option to inform a relay agent that a particular DHCP client is associated with a particular VPN. It does this by sending the Virtual Subnet Selection sub-option or option with the appropriate information to the relay agent in the relay-agent- information option for DHCPv4 or the Relay-reply message in DHCPv6. If the relay agent cannot respond correctly to the DHCP server's requirement to place the DHCP client into that VPN (perhaps because it has not been configured with a VPN that matches the VSS information received from the DHCP server) it MUST drop the packet and not send it to the DHCP client."
      if a relays requests a specific VPN, but the server returns an address not within that VPN, then the relay should drop the packet. Should the relay let the server know that it dropped the packet and why? (maybe sending a release packet?) Otherwise, Won't the server assume the address has actually been assigned to the client, thus reducing the pool of available addresses? Could an attacker, masquerading as a relay-agent use this behavior to create a DoS attack?
    4. Russ Housley: Comment [2012-01-03]:
      The Gen-ART Review by Roni Even on 1-Jan-2012 includes some editorial suggestions. Please consider them.
    5. Peter Saint-Andre: Comment [2012-01-03]:
      This is a fine document. There is one issue I'd like to mention, namely, the term "NVT ASCII VPN identifier" is underspecified. This term might refer to something like "an identifier containing characters only from the ASCII repertoire (i.e., %d32 to %d126 inclusive) using the Network Virtual Terminal (NVT) encoding [RFC5198]". If that is more accurate, feel free to use the text or initiate a conversation about appropriate changes. Also, please expand "NVT" on first use.
    6. Sean Turner: Comment [2012-01-04]:
      I modified this discuss to add some more nits I found:
      I'm curious about the answer to David's discuss.
      Nits:
      s3.2: r/see Section 35./see Section 3.5.
      s3.3: r/This sub-option only only/This sub-option only
      s5: r/DHCPvr4/DHCPv4

    Telechat:

  2. IPPM standard advancement testing (BCP)
    draft-ietf-ippm-metrictest-05
    Token: Wesley Eddy
    Note: Henk Uijterwaal (henk@uijterwaal.nl) is the document shepherd.
    Discusses/comments (from ballot 3976):
    1. Stewart Bryant: Comment [2012-01-04]:
      s/Pseudo WIre/Pseudowire/
    2. Ralph Droms: Comment [2011-10-30]:
      I have just one small editorial comment. I can't parse this test from Section 2; it might need some clarification:
      "o The error induced by the sample size must be small enough to minimize its influence on the test result. may have to be respected, especially if two implementations measure with different average probing rates."
    3. Adrian Farrel: Comment [2012-01-02]:
      A useful document, thanks.
    4. Pete Resnick: Comment [2011-12-28]:
      I think that the use of 2119 language in here is superfluous, if not just wrong. I don't see what difference it makes to a reader of this document to say, e.g., "The conditions for which the ADK test has been passed with the specified confidence level must be documented" instead of "MUST be documented."
    5. Dan Romascanu: Comment [2011-12-19]:
      (blank)
    6. Peter Saint-Andre: Comment [2012-01-03]:
      Overall this is a fine document.
      I concur with those who have commented regarding RFC 2119 language -- in many places I think you could just as easily change the text to use "needs to", "ought to", and "might" with no harm to the meaning. (For example: "The methods proposed here *might* be generally applicable....")
    7. Robert Sparks: Comment [2011-11-02]:
      I support each of Dan's discuss points, and with Sean's observation about code components.
      There are several places where 2119 keywords are used in non-meaningful ways. It would strengthen the document to review and remove the instances that are not truly needed. (The use of RECOMMENDED at the top of page 10 is a particularly strong example.)
      When you update the document to take RFC 6410 into account, please note that while interop reports are no longer required in general, if you have consensus to do so, you can still require them for advancing these metric definitions. If you chose not to require them, please consider text strongly encouraging them.
      There are several places where you REQUIRE something "whenever possible". That leaves a lot of vagueness in the specification (is "it costs too much" a reasonable excuse for "not possible"?). Please consider removing the exception clause, or at least explicitly discussing what to do or what it means when meeting that requirement is not possible.
      The first paragraph of 3.1 (stating an implementation MUST implement all the MUSTs in a specification) is vacuous - please remove it.
      Or perhaps the intent of the whole section was to clarify what's required to be reported in an implementation report and you were asking for an explicit statement that the implementation implemented all the MUSTs - if so, please clarify. That would be consistent with the second paragraph of 3.1 which appears to be asking that the report document which options were supported in "sufficient detail". But what defines sufficient, and for what purpose? Please consider continuing that sentence ("in sufficient detail to <achieve this documented goal>").
      Please consider addressing the following nits.
      The string "state of the art" isn't adding anything useful to the text - please remove it.
      The third paragraph of section 3.5 does not parse - should "by" be deleted?
      Why is there a link to xml.resource.org in the first paragraph of Appendix A.
    8. Sean Turner: Comment [2011-11-30]:
      (blank)

    Telechat:

2.2 Individual Submissions

2.2.1 New Items

  1. Collection Synchronization for WebDAV (Proposed Standard)
    draft-daboo-webdav-sync-06
    Token: Peter Saint-Andre
    Discusses/comments (from ballot 3897):
    1. Ron Bonica: Discuss [2012-01-02]:
      Downref: Normative reference to an Experimental RFC: RFC 5842
      I don't see RFC 5842 in the downref registry and I don't see any reference to the downref in the Last Call Text.
    2. Wesley Eddy: Comment [2012-01-02]:
      I support Russ's DISCUSS, particularly wrt the 2nd item noted in David Black's review, regarding atomicity.
    3. Adrian Farrel: Comment [2011-12-31]:
      I have no objection to the publication of this document as an RFC.
      A minor nit...
      Section 3.1: s/since one point in time/between one point in time/
    4. Stephen Farrell: Comment [2011-12-31]:
      I wondered if the result truncation scheme in 3.6 implies that the token is not really opaque.
    5. Russ Housley: Discuss [2011-12-31]:
      The Gen-ART Review by David Black on 27-Dec-2011 raises two major issues and one minor issue. They deserve a response.
    6. Pete Resnick: Discuss [2012-01-03]:
      1. I am concerned enough about the atomicity issue that I need to note my own DISCUSSion point. I'm not convinced that David Black's proposed solution is correct: If none of the items you have retrieved have changed before you ask for the next token, you *do* have a consistent copy of the collection, albeit old. There is no indication in the document that the mere taking of a report and return of a new token invalidates the old token (and I think the text should be clear about the expected behavior of the server; see #2 below), so I think this might be sufficient and David's solution might be overkill. Either way, I think this topic needs serious discussion in the document.
      2. The expected semantics of the server are way underspecified and I'm worried you are going to get into an IMAP-like debacle where servers are allowed in the protocol to do random crap. The document says:
      "(DAV:valid-sync-token): The DAV:sync-token element value MUST be a valid token previously returned by the server. A token can become invalid as the result of being "out of date" (out of the range of change history maintained by the server), or for other reasons (e.g. collection deleted, then recreated, access control changes, etc...). [3.2]"
      That is *way* under-specified. If you get into the nonsense of "the server can invalidate the token whenever it feels like it", you will have a completely non-interopable system. The server needs to have reasonable expectations of the kind of cache it needs to keep, and the client needs to have reasonable expectations of what a server is required to do. At least one of those expectations MUST be that the act of using a token and getting a new one does not in itself invalidate the old one.
      I am willing to clear this DISCUSS if I am told that the consensus in the WebDAV community is that this sort of random server behavior has always been acceptable to the community, but I would prefer if the spec was tightened to give more guidance to implementers.
    7. Pete Resnick: Comment [2012-01-03]:
      The security consideration is really a performance consideration. Though it can be used for nefarious DoS attacks, it can also be used by legitimate though stupid clients. I don't think it belongs in security considerations.

    Telechat:

  2. URI Template (Proposed Standard)
    draft-gregorio-uritemplate-07
    Token: Peter Saint-Andre
    Note: Murray Kucherawy <msk@cloudmark.com> is the Document Shepherd.
    Discusses/comments (from ballot 4032):
    1. Ron Bonica: Comment [2012-01-02]:
      Please run the nit-checker over this document. It appears to have a couple of unused references.
    2. Wesley Eddy: Comment [2012-01-02]:
      This seems to be a very useful and well-written document.
    3. Adrian Farrel: Comment [2011-12-31]:
      I have no objection to the publication of this document as a Standards Track RFC. I have a few very minor comments you might look at.
      You may note that you use RFC 2119 language in Section 1.1 but do not include the explanation until Section 1.5.
      Should you provide references for WSDL, WADL, and OpenSearch in section 1.3?
      In section 1.5 there is a minor notational discrepency. You have:
      "ALPHA = %x41-5A / %x61-7A ; A-Z / a-z "
      "DIGIT = %x30-39 ; 0-9 "
      "HEXDIG = DIGIT / "A" / "B" / "C" / "D" / "E" / "F" "
      That means that HEXDIG has a mixed mode of hex notation and quoted letters. It might have made more sense to write...
      "HEXDIG = DIGIT / %x41-46 ; 0-F "
      But I struggle to see this as in any way an important comment! Maybe more interesting is to check that you really intended to exclude lower case alpha from the representation of hex numbers used in pct encoding.
      While Appendix A begins with a helpful note that the body of the document is normative text, it doesn't actually comment on whether the appendix is normative or not. It would be nice to make this explicit.
    4. Stephen Farrell: Comment [2011-12-30]:
      - End of p12 says "If a value provided by a user" which implies that all the usual injection attacks need to be countered in at least some deployments. Why doesn't that need to be mentioned in the security considerations? I don't think 3986 envisages that kind of issue. (Esp. if templates were combined with OAuth v1 or something else that authenticates the URL after expansion, meaning that the user at the browser could not have produced the URL herself.)
      - Can expressions be nested?, e.g. "{foo{bar}baz}" 1st sentence of 3.2 implies not, but in any case it might be worth adding a sentence saying that nesting like that is not supported.
      - Expressions can be obfuscated. That could provide a new attack vector: expression author convinces webmaster that template is safe when its not. Not sure if that's worth a mention or not.
      - Seven operators; lists of variable with optional modifiers (esp "explode") - that all seems to me like too much to be universally useful and safe. Just an opinion, not a discuss.
    5. Russ Housley: Discuss [2012-01-03]:
      The Gen-ART Review by Vijay Gurbani on 1-Jan-2012 raised two minor issues. I have not seen a response to this review, but I believe it deserves a response. The two issues are repeated below.
      - S3.2.1, first paragraph: "A variable defined as an associative array of (name, value) pairs is considered undefined if the array contains zero members or if all member names in the array have undefined values."
      Here, do you mean "if all member names in the array have no values."? That is, "undefined values" implies that values are present in the template, but are not understood. On the other hand, "no values" implies the absence of any values at all. In my reading of the text, it appears that "no values" conveys more context than "undefined values".
      - S4, general comment: I am not sure where the template expansion is done --- at the client (browser) or at the origin server (the draft does not enunciate this, and if it does, I may have missed it). If the expansion is done at the origin server, I suspect that one can keep it a bit more busy by asking it to perform unnecessary template expansion for a resource that may be accessed normally even without template expansion. Is it worth documenting this at all in the Security Considerations section? (Clearly, if the expansion is done at the client, then it is the client incurring the expense of expansion. Insofar as the client is malicious, it is best to let it expend as much effort as necessary.)
    6. Pete Resnick: Comment [2012-01-04]:
      2.2: I'm not clear from what is said in section 3 or Appendix A what happens when an op-reserve appears in a template that is being processed where the processor doesn't recognize these operators, in particular '$', '(', and ')'. Are they all treated as error conditions? If so, where in the algorithm.
      2.3: Do you really want varnames to be able to end with "." or "_" or begin with "_" or pct-encoded? If you want only internal ".", then you want:
      varname = varchar *(["."] varchar)
      If you only want internal "_" and pct-encoded as well, then:
      varname = ALPHA / DIGIT *(["_" / "." / pct-encoded] / ALPHA / DIGIT)
      I don't care, but the current construct (can't begin with ".", but otherwise anything goes) seemed like an odd choice.
      2.4.1: An upper limit on max-length might be a useful addition.
      3.2.1: The current text says: "...If the value contains multibyte UTF-8, care must be taken to avoid splitting the value in mid-character: count each Unicode codepoint as one character."
      The admonition in 1.6 seems equally useful for the values variables: Though they might exist as encoded, all contents of variables are assumed by the spec to be Unicodes, and must be appeneded by UTF-8ing them and pct-encoding as necessary. I think it's worth adding text on this.

    Telechat:

2.2.2 Returning Items

  1. (none)

3. Document Actions

3.1 WG Submissions

3.1.1 New Items

  1. The Common Log Format (CLF) for the Session Initiation Protocol (SIP): Framework and Data Model (Informational)
    draft-ietf-sipclf-problem-statement-09
    Token: Robert Sparks
    Note: Peter Musgrave (musgravepj@gmail.com) is the document shepherd.
    Discusses/comments (from ballot 3892):
    1. Jari Arkko: Comment [2012-01-05]:
      I think we need a log file format. And it needs to work on application level, because, as noted, layer 3 or 4 security makes it impractical to read off the contents of SIP messages.
      I'm less convinced about the specific proposal here. The text on wireshark for instance seems to indicate some lack of information on various logging mechanisms in the Internet. (Wireshark is just a tool that operates on the more general pcap http://en.wikipedia.org/wiki/Pcap interface.)
      I would guess that there are multiple needs in this space. One is for detailed SIP message logging for debugging and statistics purposes. For that purpose, a pcap-like recording of exact messages at the application layer might be more appropriate. Another need is for more high-level, CDR/billing/high-level statistics collection type of needs. There some summary of SIP events would be more appropriate. This would not necessarily record every message, and could even record some non-message events such as when the SIP entity gives up on trying to contact someone. The current design seems to be some mixture of these two kinds of approaches.
    2. Stewart Bryant: Discuss [2012-01-03]:
      I would like to discuss with the authors whether the data model is an example or is definitive? If it is definitive why is it in an informational draft, and indeed why is it not in an IANA registry?
      If it is not definitive, then please can this be made clearer in the document.
    3. Ralph Droms: Discuss [2012-01-03]:
      The exact purpose and intended use of this document is not clear to me. The document name include "problem-statement," the title includes "Framework and Data Model," and the abstract concludes with the sentence:
      "We propose a common log file format for SIP servers that can be used uniformly by user agents, proxies, registrars, redirect servers as well as back-to-back user agents."
      I don't know if the text in section 4 is referring to the standards track CLF as defined in this document or an hypothetical CLF to be defined based on the problem statement in section 3 and the data model in section 8. In fact, it seems that section 8 defines something more than just a data model, as it defines mandatory elements in CLF records, etc.
      The document needs a clear statement about whether or not it is defining the operational abstraction for the standards CLF. If it is defining that standards CLF, it needs to be a standards track document.
    4. Ralph Droms: Comment [2012-01-03]:
      Editorial observation: "CLF format" is redundant.
      Process comment - the IESG Writeup Working Group Summary consists of one sentence: "The problem statement was not contentious." I can't tell if this sentence refers to just the problem statement in section 3 or the entire document. I note that the document name includes "problem-statement" while the title includes "Framework and Data Model." Perhaps the goals and purposes of the document changed during its development? It would be helpful if the Working Group Summary gave more detail about the background, development and purpose of the document.
      Niggling irritation - the first couple of motivations listed in section 6 are relevant to the development of a CLF. The remainder don't actually depend on a CLF; a CLF might ease the development of solutions to those problems.
      Which representation format is used in the example in section 9.1, or is the example an abstract representation independent of any specific format like the one defined in draft-ietf-sipclf-format-03?
    5. Wesley Eddy: Comment [2012-01-04]:
      I support Stephen & Ralph's DISCUSS points
    6. Adrian Farrel: Comment [2012-01-02]:
      Although this document does not define a CLF for SIP, I am not clear why the data model here is not normative as a Standards Track document.
      I wonder if you could consider adding to Section 7 a discussion of the migration / backward-compatiblity issues. Maybe these are no worse than today, but it will certainly be the case that a log file will need to contain some indication that it is in the CLF.
    7. Stephen Farrell: Discuss [2011-12-31]:
      This seems like a lot more than a problem statement. I'm not clear whether the security and privacy considerations here will be relied upon in the format spec or not. At present, -05 of the format draft says that this document says all that needs to be said, which is not something with which I agree. So, for now, I'm treating the security considerations here as those that will be provided as the final output of the sipclf WG. (Were this only a problem statement then that'd not be the case.)
      #1 While this document might not be able to say how files are to be protected, both locally and in transit, it could easily, and IMO, should, state requirements for that using 2119 MUSTs and also include some examples of how to meet those, e.g. REQUIRE mutual authentication, confidentiality and integrity for transfers with the example that use of mutual auth TLS between nodes accomplishes this. (Note: I'd be fine if this were instead handled in the format document since that's I guess what most coders will read.)
      #2 IP src&dest and SIP to&from are mandatory - that's not very privacy friendly. Did the WG consider this? Did the WG consider defining an additional (less sensitive, more easily shared) format where those are obfuscated (but so as to still allow correlation?) If so, why wasn't that adopted? If not, doesn't that warrant consideration? (As-is sharing CLF files is likely to be tricky from at least an EU data protection p-o-v if there are some cross-border nodes involved.)
    8. Stephen Farrell: Comment [2011-12-31]:
      - What does "trace a call from one entity to another mean"? I do hope we're not proposing that lawful intercept is the primary reason for this work.
      - You say a few things the CLF is not at the end of section 4, would it be reasonable to add "The SIP CLF is not a tool for supporting lawful intercept."
      - Public access to the log is worse than network sniffing in at least two respects - log access trumps TLS and also network sniffing is more restricted in time and place (topology).
    9. David Harrington: Discuss [2012-01-04]:
      1) I agree with the other IESG members who think this exceeds the scope of a problem statement.
      2) I agree with the DISCUSS that the shepherd writeup is lacking in useful detail. In my opinion this writeup is woefully inadequate to reflect the nature of the discussions that occurred, some contentious.
      3) The document fails to include any summary of WG discussions of using existing IETF protocols.
      There was significant contention in the WG about whether existing IETF standard data modeling languages, such as syslog structured data elements [RFC 5424] or ipfix Information Elements [RFC5655] could have been used for SIP logging. If this document is going to discuss why Apache CLF and Wireshark do not meet sipclf needs, which I believe it should, then the document should also explain the WG considerations for using syslog, ipfix, and psamp data models for SIP logging. This gap between existing standards and the problems prompting a new sipclf approach should be documented as part of the problem space.
      There was contention about whether the logging should be designed only for logging locally, or for local use and for being transported between systems. The WG discussed the need for secure transport of logged information. Existing standards already address this, e.g. syslog/TLS [RFC5425] and ipfix RFC5101]. This should be documented as part of the problem space.
      The WG debated whether pre-filtering was a desirable feature, to control log growth rates, and bandwidth needed for transporting logs, and whether existing standards could be utilized for this purpose (ipfix offers a template approach that controls what data gets logged, and what data gets transported). This should be documented as part of the problem space.
      4) The document describes wireshark as inappropriate because the wireshark libraries would need to have sipclf functionality implemented across multiple OSes and configurations. But the proposed solution seems to be to develop a whole new format, so any tools for parsing this new format would need to be developed from scratch, across multiple OSes and configurations. That strikes me as an odd problem statement to justify a new sipclf approach.
      5) I support the Discusses about whether the sipclf mandatory fields in section 8 is normative. If this is not normative, then RFC2119 language is probably inappropriate. If it is normative, then it belongs in a standards track document.
      6) Security considerations discusses the threats associated with stored logs. Existing standards for logging include capabilities for signing logs and detecting deletions and modifications [RFC5848], whether at rest or in transit. The potential need to secure logs at rest and in transit is part of the problem with logging SIP, and should be documented as part of the problem space.
    10. David Harrington: Comment [2012-01-04]:
      1) section 6 strikes me as marketing claims for the wonderful things that a sipclf can provide. But these tools are not part of the scope of sipclf development. I question whether these claims of tools that could be developed really is part of a problem statement.
      2) RFC 3444 describes the difference between Information models and Data models. If section 8 is not a normative data model, then it should probably be called an Information model, rather than a data model.
    11. Pete Resnick: Comment [2012-01-04]:
      Seems like others have the DISCUSS points well in hand.
      It seems a bit goofy in section 8.1 to call out fields as "mandatory" and even say that they are "minimal information that MUST appear in any SIP CLF record", and then go on in section 9 to point out for some items: "When a given mandatory field is not applicable to a SIP entity, we use the horizontal dash ("-") to represent it." That would make the field pretty clearly non-mandatory.
    12. Dan Romascanu: Comment [2012-01-04]:
      In the 'Operational guidance' section:
      "SIP CLF log files will take up substantive amount of disk space depending on traffic volume at a processing entity and the amount of information being logged. As such, any enterprise using SIP CLF should establish operational procedures for file rollovers as appropriate to the needs of the organization."
      I suggest to replace the word 'enterprise' with 'organization'. The issue is certainly present in all type of networks, not only in enterprise deployment as it may be mis-understood here.
    13. Peter Saint-Andre: Discuss [2012-01-04]:
      I'd like to chat about internationalization. Section 8 mentions draft-ietf-sipclf-format as an example of a representation format that provides an ASCII-based encoding scheme. Are there any examples of encoding schemes that allow code points outside the ASCII range? More generally, what are the internationalization requirements for SIP logging? The requirements might be "none" if SIP messages cannot contain, say, UTF-8 encoded Unicode characters, but if so then it would be best for the specification to make that explicit.
    14. Peter Saint-Andre: Comment [2012-01-04]:
      The document states that the Wireshark format cannot be used because "if the SIP messages are exchanged over a TLS-oriented transport, Wireshark will be unable to decrypt them and render them as individual SIP headers." Is there a reason why SIP servers cannot use the Wireshark *format* as a CLF even if they cannot use the Wireshark *application* on the data sent over an encrypted channel?
      A true nit: there is no such thing as "12:00 PM".
      Another nit: I have never seen "pend" as a verb. I suggest "can be in a pending state" or somesuch.
      When talking about URIs in Section 8, an informational reference to RFC 3986 would be appropriate.
      The allowable values for the Message type field are 'R' (for Request) and 'r' (for response). Is it really a good idea to use values that differ only by case? (Also, the Directionality field has a value of 'r' -- another source of possible confusion; you might consider "o" and "i" for outbound and inbound instead of "s" and "r" for sent and received.)

    Telechat:

  2. LFA applicability in SP networks (Informational)
    draft-ietf-rtgwg-lfa-applicability-04
    Token: Stewart Bryant
    Note: Alvaro Retana (alvaro.retana@hp.com) is the document shepherd.
    Discusses/comments (from ballot 3969):
    1. Jari Arkko: Comment [2012-01-05]:
      Nice doc!
    2. Wesley Eddy: Comment [2012-01-02]:
      In Section 3.8, under "Intra Area Destinations", the Node Protection evaluations use "Full" rather than "yes", which is inconsistent with the explanation of terms at the beginning of the section and with the terms used for the next subsection for "Inter Area Destinations".
    3. Adrian Farrel: Comment [2012-01-04]:
      I have cleared my Discuss and moved to a Yes ballot. Thanks for addressing some of my comments.
      I still wish the I-D would spend more time looking at the security (are rpf checks commonly used in the topologies that are discussed, and if so what will be done to improve security when rpf checks are disabled) and management (what will be the consequences for management of turning on LFAs in the topologies discussed). But I don't think this is a blocking concern.
      Section 2 starts with... "In this document, we assume that all links to be protected are point-to-point."
      The introduction has not mentioned the need to protect any links (nor what the concept of a protected link is).
      ISIS and OSPF should have references in Section 2.
    4. Russ Housley: Comment [2012-01-05]:
      The Security Considerations say: "This document does not introduce any new security considerations." I am sure this is true, but it does not really help the reader. Please add a sentence pointing the reader to security considerations from IP/MPLS.
      The late Gen-ART Review by Suresh Krishnan on 4-Jan-2012 includes a good suggestion. Suresh suggests:
      This draft needs an informative reference to RFC5286. Without this reference it is very difficult to get the context required to understand this draft. Please consider adding the reference.
    5. Peter Saint-Andre: Comment [2012-01-04]:
      Personally I found this document to be nearly impenetrable, but that's probably because the air is so thin up here at the application layer. :) I am balloting "No Objection" on the assumption that our Routing ADs have performed up to their usual high standard of excellence.

    Telechat:

3.1.2 Returning Items

  1. (none)

3.2 Individual Submissions Via AD

3.2.1 New Items

  1. Experiences from an IPv6-Only Network (Informational)
    draft-arkko-ipv6-only-experience-04
    Token: Ron Bonica
    Discusses/comments (from ballot 4018):
    1. Adrian Farrel: Comment [2011-12-31]:
      Thank you for an informative and readable document.
      If you were to have time to provide some additional words about management (in addition to the brief paragraph in section 8) it would be enlightening.
      - What was the user's experience of performing manual configuration where necessary? Is it the same as for v4 or messier?
      - What was the user's experience of running diagnostic tools to determine configuration and connectivity problems? Are the tools up to the same standard as for v4?
    2. Stephen Farrell: Comment [2011-12-30]:
      Good to see stuff like this.
      general:
      - A timeline would help readers understand the level of effort, e.g. if you could give dates for when stuff happened related to a specific user's home being added, or anything else that gives the right flavour for the level of effort.
      - Some ascii art n/w diagrams would be nice if you've time.
      - Some version numbers (esp. for stuff that didn't work) would be good for someone reading tihs in a few years time or who wants to try replicate your results
      - It'd be good if you added your wget scripts as an appendix or put 'em at some URL (again so folks can replicate) - 3rd last para of 6.2 seems to imply that'd be useful (and that matches my own experience too)
      - Is the DNS64/NAT64 setup you're recommending not more "wiretap" friendly than a currently typical IPv4 or dual-stack network where DNS and NAT are less coupled? Either way, that'd be worth noting I think in section 9.
      specific
      - be good to point out that you don't in general need to add new APs (3.1, 1st para)
      - saying it "becomes crucial" that you can find DNS servers doesn't explain why that's harder which may be worth saying (3.2 1st para)
      - s/a year and half/a year and a half/ (s4, 1st para)
      - You mention Ercisson and Skype (negatively in the latter case) but are coy about the mobile OSes (presumably IOS and Android). I'd say do one or the other.
      - s/only couple of times/only a couple of times/
      - 5.1 - expand RA on 1st use
      - s/result require/results require/ or /result requires/ in 5.4
      - which year is "next year" in section 8? s/next year/YYYY/
      - s/cleaned from/cleaned of/ IPv4 literals

    Telechat:

  2. The Canonical Link Relation (Informational)
    draft-ohye-canonical-link-relation-04
    Token: Peter Saint-Andre
    Discusses/comments (from ballot 4035):
    1. Stewart Bryant: Comment [2012-01-03]:
      I support Russ's discuss and wonder if "Canonical" is actually the correct term. Canonical normally implies a more precise equivalence than the author describes in the document. I think that the text is describing the preferred link relation.
    2. Wesley Eddy: Comment [2012-01-02]:
      In Section 5, the first and third recommendations may be very difficult to use practically for sites where the majority of content is generated dynamically. I don't think this document makes clear/strong enough statements on how this would/could/should be used for dynamic versus static resources, however, I defer to the judgement of the ADs closer to this topic.
    3. Adrian Farrel: Comment [2012-01-03]:
      I cleared my Discuss after an exchange with the AD.
      Building on Brian's review in Russ's Discuss...
      If URIs are identical there is surely no isse to designating one of them as preferred. They are the same, and selecting any one is the same as selecting any other.
      I suspect this is just loose language since it is obvious from the content (versus the Abstract) that you mean that it is the identical nature of the content returned by URIs that is what you define as making the URIs identical.
      Maybe you could go over this with a pedant's eye?
      Section 3 contains some examples of "SHOULD NOT". The subsequent paragraphs got my hopes up by starting with "MAY", but actually they do not address the exception cases of the "SHOULD NOT." Since you have chosen "SHOULD NOT" rather than "MUST NOT", you need to explain the option for varying the rule.
      Section 5: "Before adding the canonical link relation, verification of the following is recommended:"
      Is that "RECOMMENDED"?
    4. Stephen Farrell: Comment [2011-12-30]:
      - A non-compromised site might also well lie about which URI is "canonical" for various purposes.
    5. Russ Housley: Discuss [2011-12-31]:
      The Gen-ART Review by Brian Carpenter on 14-Dec=2011 raised one minor issue that deserves a response. The review says:
      "The canonical link relation specifies the preferred URI from a set of URIs that return identical or vastly similar content, ..."
      I don't understand the phrase "vastly similar". I don't understand what algorithm tests for vast similarity.
      The same applies to "extremely similar" in section 3 and "similar to" in section 5. Also, "similar to" is weaker than "vastly similar" or "extremely similar"; so does section 5 intend to weaken the earlier text? It seems that exactly the same phrase should be used in each case (not just a vastly similar phrase).
      This doesn't matter so much when it's a human designating the canonical relation. But it can only be a matter of time before code starts to do this (which page is canonical among a set of generated pages?). A vague word like "similar" turns this into an AI problem.
    6. Robert Sparks: Comment [2012-01-04]:
      Please consider adding text explaining when a user might choose to go against the SHOULD NOTs in section 3.
      It might help to cast the last 4 bullets in section 3 as requirements on maintaining the link relation, rather than just creating it. You might also make it clear whether transient errors are of concern in the 3rd bullet.
    7. Sean Turner: Comment [2012-01-02]:
      I too tripped over the concept of canonical being used in the same sentence as vastly/extremely similar; therefore, I support Russ' discuss.

    Telechat:

  3. DKIM Authorized Third-Party Signers (Experimental)
    draft-kucherawy-dkim-atps-15
    Token: Sean Turner
    Note: Barry Leiba (barryleiba@computer.org) is the document shepherd.
    Discusses/comments (from ballot 4039):
    1. Adrian Farrel: Comment [2012-01-02]:
      Thank you for advancing this work as Experimental and for taking the time to describe the experimental process.
    2. Stephen Farrell: Comment [2012-01-01]:
      (blank)
    3. Russ Housley: Discuss [2012-01-03]:
      IANA suggests that the registry be created now, even if it will not be used for some time. Thanks to Alexey Melnikov for asking the question in his Gen-ART Review.
    4. Pete Resnick: Comment [2012-01-03]:
      1. "ATPS" is never expanded in the text before its use. Please do so in the intro.
      2. The ABNF for atps-query should put an upper limit of 63 for the number of BASE32 characters:
      "atps-query = 1*63BASE32 %x2e.5f.61.74.70.73.2e domain-name"
      3. Is there reason to believe that, in practice, the hashing is really needed? Do we really believe that the combination of the two domain names will exceed 255 characters?
      4. Given that this is an experiment, is there any reason not to give this a go with a new DNS query type? (Yeah, yeah, I know. But I thought I'd ask.)
    5. Peter Saint-Andre: Comment [2012-01-04]:
      This is a fine document. It's especially helpful to describe how the experiment will be run.
      I have one small comment: please consider adding a brief sentence about internationalized domain names (IDNs). I realize that RFC 6376 specifies encoding of IDNs as A-labels, but it might be good to reinforce that message here, such as (in Section 4.2):
      "domain-name" and "key-h-tag-alg" are defined in [DKIM]. Note that according to [DKIM] internationalized domain names are to be encoded as A-labels, as described in Section 2.3 of [RFC5890].
      This would necessitate adding an informative reference to RFC 5890, if you decide to make such a change.

    Telechat:

  4. The Item and Collection Link Relations (Informational)
    draft-amundsen-item-and-collection-link-relations-04
    Token: Peter Saint-Andre
    Discusses/comments (from ballot 4049):
    1. Stewart Bryant: Comment [2012-01-03]:
      I agree with Adrian's comments
    2. Wesley Eddy: Comment [2012-01-02]:
      The usefulness of this was not really clear to me, and the references are either just webpages or works-in-progress, so it's unclear to me whether it's really in-use or will actually be used. However, I'm not personally concerned with the tidiness of this registry and trust the judgement of the ADs closer to it.
    3. Adrian Farrel: Comment [2011-12-31]:
      I have no objection to the publication of this document as an RFC, but I have a couple of Comments you could look at along the way.
      I found it odd that this "specification" is Informational since it does define things.
      The RFC Editor will want you to remove the citation from the Abstract. If you are providing a revised version, please fix this.
      I would have preferred you to explicitly name the registry in which you want new entries recorded.
    4. Stephen Farrell: Comment [2011-12-30]:
      Would it be worth saying whether both item and collection can occur in the same href?
    5. Russ Housley: Discuss [2012-01-03]:
      The Gen-ART Review by Mary Barnes on 2-Jan-2012 raised a point that deserves a document update:
      ID nits indicates that "You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009."
    6. Sean Turner: Comment [2012-01-01]:
      For the secdir reviewer:
      s4: r/are not believed to/do not

    Telechat:

3.2.2 Returning Items

  1. (none)

3.3 IRTF and Independent Submission Stream Documents

3.3.1 New Items

  1. (none)

3.3.2 Returning Items

  1. (none)

1215 EST break

1300 EST back

4 Working Group Actions

4.1 WG Creation

4.1.1 Proposed for IETF Review

  1. RTP Media Congestion Avoidance Techniques (rmcat)
    Token: Wes

    Telechat:

4.1.2 Proposed for Approval

  1. SPF Update (spfbis)
    Token: Pete

    Telechat:

4.2 WG Rechartering

4.2.1 Under evaluation for IETF Review

  1. Distributed Mobility Management (dmm)
    Token: Jari

    Telechat:

  2. Locator/ID Separation Protocol (lisp)
    Token: Jari

    Telechat:

  3. Routing Area Working Group (rtgwg)
    Token: Stewart

    Telechat:

  4. Diameter Maintenance and Extensions (dime)
    Token: Dan

    Telechat:

  5. IP Security Maintenance and Extensions (ipsecme)
    Token: Sean

    Telechat:

4.2.2 Proposed for Approval

  1. (none)

5. IAB News We can use

6. Management Issues

  1. Adding ONF to New-Work mail list (Russ Housley)

    Telechat:

  2. RFC 6471 <draft-irtf-asrg-bcp-blacklists-10.txt> (Pete Resnick)

    Telechat:

  3. We discussed the IESG advice for cross-area work. There's a draft out, and it would be good to add it as a management item if there's time. (Jari)

    Telechat:

7. Agenda Working Group News

1401 EST Adjourned


Valid HTML 4.01 Strict


Appendix: Snapshot of discusses/comments

(at 2012-01-05 07:31:17 PST)

draft-ietf-sieve-include

  1. Jari Arkko: Discuss [2012-01-04]:
        I spent some time thinking about whether I want to say something or not.
    
    But I'll join others in worrying about the issue of recursion, but raise some of
    the comments to a level of a Discuss.
    
    I should also say that developing a programming language is difficult,
    particularly when you add tiny features one at a time (like subroutines).  For
    instance, the recursion discussion is difficult because you've conflated the
    concepts of module references and actual invocations of those modules during
    execution time.
    
    It might have been better to think about an upgrade of the sieve model in a more
    architectural manner. Or maybe the WG already did and I am just not aware of it.
    In any case, this is just a comment and not a part of my Discuss.
    
    The Discuss is the following. First, as Adrian noted you must define what you
    mean by recursion, because otherwise implementations are likely to miss that
    they need to track indirect inclusions as well: A includes B, B includes A. I
    wonder if it would have been easier just to have the concept of nesting levels
    and maxing out on them. That's how I would implement this if I was implementing
    it. No need to track recursion in specific ways.
    
    Second, I think your minimum requirement of three levels is a bit too small. If
    people actually start using this they are likely to engineer script structures
    that need more, and if not all implementations support that number of levels
    there will be breakage. I'd say five or ten would be a more reasonable minimum
    level. But I'm not asking you to put any specific number but rather I'm asking
    you think about this and make a rational decision based on some basis. (And
    again, maybe you already have and you just need to tell me what the basis of
    that decision was.)
    
    I also think that the active/other script definition for checking recursion is
    broken, but that was already raised by Russ' Discuss. 
        
  2. Adrian Farrel: Comment [2012-01-02]:
    I think it would be helpful if you spent more time explaining what you
    mean by recursion. Direct recursion is (of course) a lot easier to spot
    than general (by menas of indeirections) recursion. But it is the 
    general case you need to protect against and that is potentially 
    considerably more complicated for an implementation to police. Since
    the consequences are just as bad, and since it may be harder for the 
    coder to realise that they have transgressed, I think you should call it
    out explicitly.
    
    Perhaps add a definition of recurssion to Section 2, and then note the
    implication for tracking all nested script names in 3.1
  3. Stephen Farrell: Comment [2011-12-30]:
    Is SIEVE turning into a fully-fledged programming language? 
    I guess I wonder if that's happening by design or by accident.
    (Not that I know which would be better;-)
  4. Russ Housley: Discuss [2011-12-31]:
        
      The Gen-ART Review by Reviewer: Ben Campbell on 13-Dec-2011 raises
      some points, the authors have responded to them, but the discussion
      has not completed yet.  I believe the document needs to be updated to
      at least address Ben's first point:
    
      >>> -- section 3.1, paragraph 4: "Implementations MUST NOT generate
      >>> errors for recursive inclusions at upload time, as this would
      >>> force an upload ordering requirement upon script authors /
      >>> generators.  However, if an active script is replaced with a
      >>> faulty script and would remain the active script, an error MUST
      >>> be generated and the upload MUST fail."
      >>>
      >>> These two statements seem contradictory on a quick reading.  In
      >>> particular, how can the latter assertion avoid an upload ordering
      >>> requirement? Or do you mean faulty in some way other than being
      >>> recursive?
      >>
      >> If you're replacing an active script, it has to be correct all the
      >> time, and uploads are atomic only on a per-script basis. There's a
      >> risk that if you're uploading a set of scripts that include one
      >> another, at some intermediate stage while some scripts are uploaded
      >> but not others, they are in an invalid state. The managesieve spec
      >> says that scripts must be validated at upload time. The language
      >> above is trying to say that you can upload all of the scripts that
      >> may include one another in any order without generating errors
      >> immediately, however, if you're replacing an active script or a
      >> script included by the active script, then you DO have to upload a
      >> correct script right from the get-go.
      >
      > Is this just a question of whether the script(s) are replacing
      > active scripts? That is, the license to create a transient invalid
      > state is suspended if if you are replacing an active script? If so,
      > how would one go about updating a set of linked scripts when one or
      > more of them replace active scripts? Should one somehow deactivate
      > the old ones, load all the scripts, then activate them? 
        
  5. Peter Saint-Andre: Comment [2012-01-04]:
    Section 3.1 states:
    
       An error MUST be generated when such a script is executed.
    
    However, Section 3.2 states:
    
       Implementations MUST NOT generate an error if an "include :once"
       command names a script whose inclusion would be recursive; in this
       case, the script MUST be considered previously included and therefore
       "include :once" will not include it again.
    
    These two are in conflict. I suggest changing the text in Section 3.1 as
    follows:
    
       An error MUST be generated when such a script is executed, except 
       as noted under Section 3.2.
    
    In Section 3.2:
    
       The ":optional" parameter indicates that the script may be missing.
    
    I'd change "may" to "MAY" or (to avoid confusion with "might be missing") say
    "is allowed to be absent" or somesuch.
    
    Section 3.4.1 states:
    
       If a "global" command is given the name of a variable that has
       previously been defined in the immediate script with "set", an error
       MUST be generated either when the script is uploaded or at execution
       time.
    
    Does that impose an ordering requirement on script uploads?
  6. Sean Turner: Comment [2012-01-01]:
    1) s3.2: Contains the following:
    
       The "include" command takes an optional "location" parameter, an
       optional ":once" parameter, an optional ":optional" parameter, and a
       single string argument representing the name of the script to include
       for processing at that point.
    
    Shouldn't the "optional"s be "OPTIONAL" to ensure they match they ABNF?
    
    2) s3.2: Contains the following:
    
       Note: It is RECOMMENDED that script authors / generators use the
       ":once" parameter only when including a script that performs general
       duties such as declaring global variables and making sanity checks of
       the environment.
    
    Can you rephrase this so the requirement isn't in a "note"?

draft-ietf-6lowpan-nd

  1. Stewart Bryant: Comment [2012-01-05]:
    I agree with the points that Adrian makes.
  2. Adrian Farrel: Discuss [2012-01-03]:
        I have added a placeholder to this Discuss to ensure that Pascal Thubert's last
    call comments are resolved (one way or the other).
    
    ---
    
    This is a really small Discuss and easily fixed. The way that
    [I-D.ietf-6lowpan-hc] is used in Sections 1.4 and 3 make it a
    normative reference.
    
    ---
    
    Section 3.4 seems to contain a lot of options and sub-options with the
    over-arching assumption that "all 6LRs in a network are configured to
    perform these functions homogeneously." This seems like a lot of
    configuration complexity for very simple nodes in an environment where
    users will not be sophisticated. Moreover, it seems highly likely to me
    that misconfigurations will arise and homogeneity will be lost.
    
    The latter suggests that the assumption of homogeneity cannot be
    trusted. You will need to handle (at least at the level of fault
    detection) mixed mode configuration.
    
    The former suggests that you should have some form of automatic
    arbitration (i.e., something more sophisticated than fault detection) so
    that the network can become homogeneous across the sub-options.
    
    ---
    
    Table 1 in Section 4.1 demands an IANA action. In Section 12 there is a
    brief statement:
    
       This document also requests IANA to create a new registry for the
       Status values of the Address Registration Option.
    
    This text needs to be beefed up to show:
    - which is the owning registry
    - what the name of the sub-registry should be
    - either a pointer to section 4.1 or (preferably) all of the relevant
      information
    
    ---
    
    Section 6.1
    
       A router SHOULD NOT send Redirect messages in a route-over topology,
       but MAY send Redirect messages in a mesh-under topology.
    
    The use of 2119 language here may be correct, but leaves some holes.
    
    In route-over, under what conditions MAY a router send Redirect
    messages?
    
    In mesh-under, what is the normal behavior? Presumably "SHOULD NOT". But
    why MAY a Redirect be sent in mesh-under?
    
    ---
    
    Section 12
    
    Please remove the following text from the I-D before advancing it to the
    RFC Editor
    
       For the purpose of protocol interoperability testing of this
       specification, the following values are being used temporarily:
    
       o  TBD1 = 31
    
       o  TBD2 = 32
    
       o  TBD3 = 33
    
       o  TBD4 = 155 XXX
    
       o  TBD3 = 156 XXX
    
    (There is, in any case, a typo s/TBD3/TBD5/ on the last line)
    
    ---
    
    Section 8.2.1
    
       A node MUST silently discard any received Duplicate Address Request
       and Confirmation messages that do not satisfy all of the following
       validity checks:
    
    I suspect you mean "...message that does not satisfy any of the
    following..." Since you have written that only the messages that fail
    every one of the checks must be discarded. 
        
  3. Adrian Farrel: Comment [2011-12-31]:
    A strict reading of one sentence in the Abstract may be misleading...
    
       The traditional IPv6 link concept and heavy use of multicast
       make the protocol inefficient and sometimes impractical in a low
       power and lossy network.
    
    This reads as though it is IPv6 that is inefficient/impractical. Maybe
    
    NEW
       The traditional IPv6 link concept and heavy use of multicast
       make the Neighbor Discovery protocol inefficient and sometimes
       impractical in a low power and lossy network.
    END
    
    ---
    
    "LoWPAN" is not yet in the RFC Editor's registry of "well-known"
    acronyms indicated by an asterix at
    http://www.rfc-editor.org/rfc-style-guide/abbrev.expansion.txt
    (Actually, it is not on that page at all!)
    
    You may want to encourage your AD to lobby for it to be added. In the
    meantime, please expand it on first use (by adding it in the first
    sentence of the Abstract, and by expanding it in the second sentence of
    the Introduction).
    
    A reference to a wider and more detailed definition of a 6LoWPAN might
    also be helpful.
    
    ---
    
    The language in section 1.2 describing the differences between mesh-
    under and route-over introduces some ambiguity by slightly careless
    use of language. The problem arises from trying to distinguish between
    routing (at the IP layer) and link-layer routing. Similarly by saying
    that in mesh-under all "hosts" are on the same link, yet that forwarding
    is handled by a link-layer mesh routing protocol.
    
    I don't think there is anything here that is unusual to people familiar
    with layered networking. You might make the text crystal clear by
    explaining the existence of layers and then refering always to "links in
    the IP layer" and "routing in the Ethernet layer".
    
    While a lot of my gripe is my own sensitivity to mesh-under being
    proposed for environments where IP routing is more appropriate, I do
    think you may add value to the document by some clarification in this
    section.
    
    Similarly, a little more tightness in Section 2 might help. For example,
    a 6LR is defined as a router in a 6LoWPAN that can communicate with
    another router in the 6LoWPAN. This doesn't really say very much. What
    is routed? What is the ocnnectivity between the 6LRs?
    
    (By the way, I am not sure that the term "host" adds any clarity. For
    example...
    
       In both types of configurations, hosts do not take part in routing
       and forwarding packets and they act as simple IPv6 hosts.
    
        
  4. ...where you say that a host acts as a host!) --- Section 1.3 uses RFC 2119 language before the boilerplate is introduced in Section 2. --- Two of the bullets in Section 1.4 appear to have a minor contradiction. Viz. o A 6LoWPAN is configured to share one or more global IPv6 address prefixes to enable hosts to move between routers in the 6LoWPAN without changing their IPv6 addresses. o Since the 6LoWPAN shares one single prefix throughout the network, mobility of nodes within the LoWPAN is transparent. Inter-LoWPAN mobility is out-of-scope of this document. "one or more...prefixes" vs. "one single prefix" --- The bit numbering on the figure in Section 4.4. is misaligned. --- Should the timers and thresholds in Section 5.3 be configurable? Which of the constants in Section 9 needs to be configurable? Should Section 5.3 have a forward-pointer to Section 9? --- Section 6.2 is woolly for a specification. "More or less" ? "might want to" ? --- Several times (e.g. 6.5.5, and particularly Section 8) you say "optionally". You might want to consider using RFC 2119 language. --- Section 11 talks of rejecting DAC and DAR messages in some potential security violations. Do you mean "reject" or "discard"? --- I think Section 13 is a fine idea. However, the only text in the Section says... This section discusses a guideline of new features for implementation and deployment. Would it be possible to add a little more interprettation of the tables? By the way, I find my interpretation of the tables give rise to a few questions... If a feature is marked as "SHOULD" deploy, how would that be possible unless implementations "MUST" implement? If a feature "MUST NOT" be deployed, does it matter whether the implementation includes the option?
  5. Stephen Farrell: Discuss [2012-01-02]:
        
    #1 1.4 - "it is assumed that 6LRs register with all the 6LBRs." is
    ambiguous - does it mean each 6LR registers with some 6LBR or
    s/each/all/ or s/some/all/ or both? Assuming that all 6LRs are
    registered with all 6LBRs would seem to be too difficult and unwise
    so I think this needs fixing.
    
    #2 1.4 - Why would probabilistic uniqueness of non-EUI-64-derived
    addresses not be sufficient in some networks? If it is, then the
    "must be either assigned or checked" seems wrong.
    
    #3 3.2 - Does this mean that if I can pretend to be a router I can
    force (some) nodes to change their addresses? If so, why is that
    not mentioned as an attack in the security considerations?  (If
    IP-address based node reputation ever evolved for nodes like these
    then this would be serious attack - misbehave as addr1, pretend to
    be a DHCP server and then force addr1 on some other innocent node.)
    
    #4 3.3 - How long is a sleeping node expected to say awake when
    sending a registration message? Is that long enough to get an error
    saying its chosen address is in use already? If not, then what
    prevents that node constantly re-awakening and using the duplicate
    address (or many identical such nodes doing that all the time)?
    (Saying "A host retransmits...until..." later in that section isn't
    clear enough really - there's no 2119 language there at all so I
    don't know if that's a MUST or MAY.)
    
    #5 8.1.4 - Is the last sentence here really optional, (everything
    in section 8 should be optional, right?) or is that behaviour meant
    to apply to all cases? If the latter, it really ought be in 4.2
    shouldn't it? Also there are two 6CO's mentioned there, but its not
    clear to me at what point the 2nd is sent (T+5 presumably?)
    
    #6 What does "expects" mean in the security considerations?
    (Section 11, 2nd para.) That's not 2119 language. Are you saying
    this protocol MUST NOT be used if layer 2 security isn't
    sufficiently strong or is missing? If not, then what?
    
    #7 How can "Using link-layer indication for NUD" be a SHOULD deploy
    but only a MAY implement? (Table 2, in section 13.)  
        
  6. Stephen Farrell: Comment [2012-01-02]:
    General - The logic as to why mesh-under and route-over are the
    most important topologies is not explained here and I don't see why
    its most valuable to tackle this problem in a topology-specific
    manner.  It's also a shame that 1.3 needs to have all nodes
    implementing this to get any benefit and that each node must be
    part of only one network. (The latter is particularly unfortunate
    given that sleeping node wake times might cause such a condition
    over time.) However, this is maybe not actually a problem since the
    protocol doesn't seem to be really specific to those topologies -
    is that right? If so, then I'd suggest weakening the language to
    say that e.g. the authors or WG are more interested in those
    topologies, but that the protocol might work in other contexts too.
    
    Various places: - What's a non-transitive wireless link?  
    
    Abstract - is a bit awkwardly written, some polish could usefully
    be applied.
    
    1.1 - I don't get the relevance of the "primarily two types" of
    lowpan topology on p5. Only the last sentence of that paragraph
    seems relevant or necessary. Similarly with section 1.2 which,
    other than introducing terminology seems unnecessary.
    
    1.3 - A number of the goals say "optimize" - is that meant to mean
    "improve" or "make the best"? In the latter, case, that would seem
    to require more work, e.g. to be able to compare approaches via
    metrics or something. Since I don't think that's really needed, I'd
    say s/optimize/improve/g would be more correct. (Similarly for
    s/minimize/reduce/)
    
    1.4 - I don't know why the following assumption is needed: "A
    6LoWPAN is configured to share one or more global IPv6 address
    prefixes to enable hosts to move between routers in the 6LoWPAN
    without changing their IPv6 addresses." Why is it necessary to say
    this?  (The spec would be clearer if that were clear I think.)
    
    1.4 - please don't use the reference as part of the sentence
    "[I-D.ietf-6lowpan-hc]" being the one that stood out - surely that
    has a name?
    
    1.5 - I can't parse the first sentence.
    
    3.2 - s/required/REQUIRED/g? and is it clear what it means to
    "REQUIRE" something of a lowpan? (Rather than a node)
    
    3.3 - "suspects" seems too vague, suggest giving at least one
    precise (common) condition, and if necessary saying there may be
    others too
    
    3.3. "The registration can fail (an ARO option returned to the host
    with a non-zero Status)..." the parenthetic clause isn't clear
    there. Suggest splitting the sentence. 
    
    3.4 - What's context dissemination? Maybe needs a forward ref?
    
    3.5 - How does packet loss impact on "successfully registers with"?
    (Just wondering.)
    
    4.3 - where is "sequence number arithmetic" defined?
    
    5.3 - What are "theses packets"? Maybe a way to get a few PhDs?
    That'd be nice:-)
    
    5.3 - Where is "binary exponential backoff" defined?
    
    5.4.3 - Where is the Default router lifetime defined?
    
    5.5.3 - What does "no more default routers" mean?
    
    5.8.1 - seems wrong to say a host should consider how quickly
    topology changes, how'd it know in general? 
    
    6.2 - initialising an interface "more or less" like something is a
    vague for a spec.
    
    8.1.2 - "similarly" seems vague
    
    13 - The introductory text here is confusing - what's this section
    for really?  Does "deploy" mean "use"? I'd prefer the latter term.
    
  7. Russ Housley: Comment [2011-12-31]:
      The Gen-ART Review by Richard Barnes on 30-Dec-2011 raised one
      suggestion.  Please consider it:
      >
      > The phrase "transitive link" is unfamiliar to me.  A definition
      > would be helpful.
  8. Peter Saint-Andre: Comment [2012-01-04]:
    Adrian Farrel expressed better than I could my concerns about the complexity of
    this technology, especially given the target environment.
    
    The phrase "IP-over-foo document" is a bit vague and breezy. Could you at least
    provide an example of such a document?

draft-ietf-6man-exthdr

  1. Ron Bonica: Comment [2012-01-02]:
    This document updates RFC 2460, but I will let Adrian hold that DISCUSS.
  2. Ralph Droms: Discuss [2012-01-03]:
        I agree with Adrian and Ron that this document updates RFC 2460.
    
    I also agree with Stephen that additional discussion 
    is needed regarding how this document
    updates RFC 2460 regarding middlebox inspection
    of extension headers.  That discussion might be as simple
    as "middleboxes perform extension header inspection
    today in contradiction of RFC 2460."  The document needs
    to make the point explicitly so the IETF is aware of and can
    discuss whether or not to officially sanction such behavior. 
        
  3. Wesley Eddy: Comment [2012-01-03]:
    Extension headers are sensitive to ordering, partial deployment, and other
    issues.  I don't think the guidelines in this document mitigate these in a
    meaningful way (e.g. due to the fact that it remains unknown the intermediate
    nodes whether unrecognized extensions earlier in the chain should alter later
    extension header or upper layer protocol processing), HOWEVER, I don't think the
    guidelines are harmful either, and can see that it's desirable to have a
    recommended base extension header format.
    
    For some time, high-rate DPI that I have seen has used heuristics rather than
    actual protocol processing.  I do not think adoption of the guidelines in this
    document will alter that, though "helping" such devices seems to be a goal for
    this work.  It seems undesirable to me, in general, to restrict protocol formats
    in order to aid layer violations ... but in the case of this particular
    document, I believe no harm is done.
    
    
  4. Adrian Farrel: Discuss [2011-12-31]:
        Doesn't this update RFC 2460 such that the format of future extension
    headers is predictable? 
        
  5. Stephen Farrell: Discuss [2011-12-30]:
        
    - RFC 2460 says that "a receiver must not scan through a packet looking
    for a particular kind of extension header and process that prior to
    processing all preceeding ones" (end of p6), whereas this is saying that
    we need a way to skip unknown extensions. Those seem to be in conflict.
    Does that matter? If not, then saying *why* not would be good. (Simply
    saying "we need DPI" doesn't answer this question IMO.) If that conflict
    does matter, then what's the resolution? I don't understand how
    resolving that conflict can be "future work" in any normal sense if that's 
    what's meant by section 6.
     
        
  6. Stephen Farrell: Comment [2011-12-30]:
    - Doesn't this update rfc 2460? 
    
  7. David Harrington: Comment [2011-12-28]:
    abstract: s/past/beyond/
    	(past can also mean previous; the intro has more context for the usage)
    
    intro:
    s/absolutely essential in the Internet-Draft proposing the new option
    with hop-by-hop behavior./absolutely essential./
  8. Russ Housley: Comment [2011-12-31]:
      The Gen-ART Review by Kathleen Moriarty on 4-Dec-2011 suggested some
      editorial changes, and the author agreed to make them.  However, the
      changes have not been made yet.
  9. Peter Saint-Andre: Comment [2012-01-04]:
    My colleagues have raised a well-rounded set of questions about this document.
    In addition, I think it could say more about the impact on interoperability and
    Internet operations (these issues are mentioned in the introduction but not
    described in detail).
  10. Sean Turner: Comment [2012-01-04]:
    1) s4: Contains the following:
    
     Next Header     8-bit selector.  Identifies the type of header
                     immediately following the Extension header.
                     Uses the same values as the IPv4 Protocol
                     field.
    
    Don't you need a reference for the values?  Maybe:
    
     [IANA_IP_PARAM]
                  IANA, "IP Parameters",
                  <http://www.iana.org/assignments/ip-parameters>.
    
    2) Where do I get a ticket for the "doesn't this update 2460" bandwagon?

draft-ietf-storm-rddp-registries

  1. Jari Arkko: Discuss [2012-01-04]:
        The draft has several places where it says:
    
       Assignment policy: If the requested value is not already assigned,
       it may be assigned to the requester.
    
    This was a bit confusing because the allocation policy (e.g., Standards Action)
    came much later in the Section, and I was wondering if the above meant "FCFS".
    
    I would replace all of these with one statement at the beginning of Section 3:
    
    Allocation requests for the below registries may come with a suggested numerical
    value that should be assigned. Such suggestions are useful when early
    implementations have already chosen particular code points before the final RFC
    comes out. If the allocation request in general is accepted, such suggestions
    may be honored if the suggested value is still free to be assigned.
    
    Or some words to the same effect.
     
        
  2. Jari Arkko: Comment [2012-01-04]:
    I agree with Pete that the RFC 2119 language is in general unnecessary.
    
    In some of the registries, providing an experimental value for testing and
    development purposes would be useful, IMHO. Look at RFC 5872 Sections 2.1 and 3
    for an example and RFC 3692 for general guidance. For instance, I would reserve
    one RDMAP operation code value (0xF) as an experimental value. And 0xFFFF for
    SCTP Function Codes for DDP Session Control. But whether you want to make such a
    reservation depends of course entirely on your understanding of the needs of the
    RDDP community and how the protocols might evolve.
  3. Pete Resnick: Comment [2012-01-03]:
    I think the 2119 language is unnecessary and ought to be removed. Some of it
    belongs with the protocol that defines the field. Some of it is giving
    instructions to IANA about their processing, which seems an inappropriate use of
    2119.

draft-ietf-dhc-vpn-option

  1. Adrian Farrel: Comment [2012-01-04]:
    I still think that using the terms "relay-agent-information sub-option" and
    "relay sub-option" interchangeably adds confusion
  2. Stephen Farrell: Comment [2012-01-03]:
    - NVT ASCII could do with a reference.
    
    - Last sentence of section 5 is odd. (just before start of 5.1)
    
  3. David Harrington: Discuss [2012-01-03]:
        1. From section 5, "A relay agent which receives a DHCP request from a DHCP
    client on a VPN SHOULD include Virtual Subnet Selection information in the DHCP
    packet prior to forwarding the packet on to the DHCP server unless inhibited
    from doing so by configuration information or policy to the contrary." This
    reflects an implicit requirement; that requirement should be made explicit. -
    "DHCP relay agent implementations MUST provide a configuration knob to inhibit
    this behavior." (I'm not sure how you expect policy to be specified, but with
    the configuration knob, a policy might use the knob to enforce a policy.)
    
    2. In section 5.1,  "In some cases, a DHCP server may use the Virtual Subnet
    Selection sub-option or option to inform a relay agent that a particular DHCP
    client is associated with a particular VPN. It does this by sending the Virtual
    Subnet Selection sub-option or option with the appropriate information to the
    relay agent in the relay-agent- information option for DHCPv4 or the Relay-reply
    message in DHCPv6. If the relay agent cannot respond correctly to the DHCP
    server's requirement to place the DHCP client into that VPN (perhaps because it
    has not been configured with a VPN that matches the VSS information received
    from the DHCP server) it MUST drop the packet and not send it to the DHCP
    client."
    
    if a relays requests a specific VPN, but the server returns an
    address not
    within that VPN, then the relay should drop the packet. Should the
    relay let the
    server know that it dropped the packet and why? (maybe sending a release
    packet?)
    Otherwise, Won't the server assume the address has actually been
    assigned to the client, thus reducing the
    pool of available addresses? Could an
    attacker, masquerading as a relay-agent use this behavior to create a DoS
    attack? 
        
  4. Russ Housley: Comment [2012-01-03]:
      The Gen-ART Review by Roni Even on 1-Jan-2012 includes some editorial
      suggestions.  Please consider them.  The review can be found at:
      http://www.ietf.org/mail-archive/web/gen-art/current/msg07005.html
  5. Peter Saint-Andre: Comment [2012-01-03]:
    This is a fine document. There is one issue I'd like to mention, namely, the
    term "NVT ASCII VPN identifier" is underspecified. This term might refer to
    something like "an identifier containing characters only from the ASCII
    repertoire (i.e., %d32 to %d126 inclusive) using the Network Virtual Terminal
    (NVT) encoding [RFC5198]". If that is more accurate, feel free to use the text
    or initiate a conversation about appropriate changes. Also, please expand "NVT"
    on first use.
  6. Sean Turner: Comment [2012-01-04]:
    I modified this discuss to add some more nits I found:
    
    I'm curious about the answer to David's discuss.
    
    Nits:
    
    s3.2: r/see Section 35./see Section 3.5.
    
    s3.3: r/This sub-option only only/This sub-option only
    
    s5: r/DHCPvr4/DHCPv4

draft-ietf-ippm-metrictest

  1. Stewart Bryant: Comment [2012-01-04]:
    s/Pseudo WIre/Pseudowire/
  2. Ralph Droms: Comment [2011-10-30]:
    I have just one small editorial comment.  I can't parse this test from
    Section 2; it might need some clarification:
    
       o  The error induced by the sample size must be small enough to
          minimize its influence on the test result.  This may have to be
          respected, especially if two implementations measure with
          different average probing rates.
    
  3. Adrian Farrel: Comment [2012-01-02]:
    A useful document, thanks.
  4. Pete Resnick: Comment [2011-12-28]:
    I think that the use of 2119 language in here is superfluous, if not just wrong.
    I don't see what difference it makes to a reader of this document to say, e.g.,
    "The conditions for which the ADK test has been passed with the specified
    confidence level must be documented" instead of "MUST be documented."
  5. Dan Romascanu: Comment [2011-12-19]:
    
        
  6. Peter Saint-Andre: Comment [2012-01-03]:
    Overall this is a fine document.
    
    I concur with those who have commented regarding RFC 2119 language -- in many
    places I think you could just as easily change the text to use "needs to",
    "ought to", and "might" with no harm to the meaning. (For example: "The methods
    proposed here *might* be generally applicable....")
  7. Robert Sparks: Comment [2011-11-02]:
    I support each of Dan's discuss points, and with Sean's observation about code
    components.
    
    There are several places where 2119 keywords are used in non-meaningful ways. It
    would strengthen
    the document to review and remove the instances that are not
    truly needed. (The use of RECOMMENDED
    at the top of page 10 is a particularly
    strong example.)
    
    When you update the document to take RFC 6410 into account, please note
    that
    while interop reports are no longer required in general, if you have consensus
    to do so, you can still require them for advancing these metric definitions. If
    you
    chose not to require them, please consider text strongly encouraging them.
    
    There are several places where you REQUIRE something "whenever possible". That
    leaves a lot of vagueness in the specification (is "it costs too much" a
    reasonable excuse for
    "not possible"?). Please consider removing the exception
    clause, or at least explicitly discussing 
    what to do or what it means when
    meeting that requirement is not possible.
    
    The first paragraph of 3.1 (stating an implementation MUST implement all the
    MUSTs in a specification)
    is vacuous - please remove it.
    
    Or perhaps the intent of the whole section was to clarify what's required to be
    reported in an
    implementation report and you were asking for an explicit
    statement that the implementation
    implemented all the MUSTs - if so, please
    clarify. That would be consistent with the second paragraph
    of 3.1 which appears
    to be asking that the report document which options were supported in
    "sufficient
    detail". But what defines sufficient, and for what purpose? Please
    consider continuing that sentence 
    ("in sufficient detail to <achieve this
    documented goal>").
    
    Please consider addressing the following nits.
    
    The string "state of the art" isn't adding anything useful to the text - please
    remove it.
    
    The third paragraph of section 3.5 does not parse - should "by" be deleted?
    
    Why is there a link to xml.resource.org in the first paragraph of Appendix A.
  8. Sean Turner: Comment [2011-11-30]:
    
      

draft-daboo-webdav-sync

  1. Ron Bonica: Discuss [2012-01-02]:
        Downref: Normative reference to an Experimental RFC: RFC 5842
    
    I don't see RFC 5842 in the downref registry and I don't see any reference to
    the downref in the Last Call Text. 
        
  2. Wesley Eddy: Comment [2012-01-02]:
    I support Russ's DISCUSS, particularly wrt the 2nd item noted in David Black's
    review, regarding atomicity.
  3. Adrian Farrel: Comment [2011-12-31]:
    I have no objection to the publication of this document as an RFC.
    
    A minor nit...
    
    Section 3.1
    s/since one point in time/between one point in time/
  4. Stephen Farrell: Comment [2011-12-31]:
    I wondered if the result truncation scheme in 3.6 implies
    that the token is not really opaque.
    
  5. Russ Housley: Discuss [2011-12-31]:
        
      The Gen-ART Review by David Black on 27-Dec-2011 raises two major
      issued and one minor issue.  They deserve a response.  The review
      can be found at:
      http://www.ietf.org/mail-archive/web/gen-art/current/msg06994.html 
        
  6. Pete Resnick: Discuss [2012-01-03]:
        1. I am concerned enough about the atomicity issue that I need to note my own
    DISCUSSion point. I'm not convinced that David Black's proposed solution is
    correct: If none of the items you have retrieved have changed before you ask for
    the next token, you *do* have a consistent copy of the collection, albeit old.
    There is no indication in the document that the mere taking of a report and
    return of a new token invalidates the old token (and I think the text should be
    clear about the expected behavior of the server; see #2 below), so I think this
    might be sufficient and David's solution might be overkill. Either way, I think
    this topic needs serious discussion in the document.
    
    2. The expected semantics of the server are way underspecified and I'm worried
    you are going to get into an IMAP-like debacle where servers are allowed in the
    protocol to do random crap. The document says:
    
          (DAV:valid-sync-token): The DAV:sync-token element value MUST be a
          valid token previously returned by the server.  A token can become
          invalid as the result of being "out of date" (out of the range of
          change history maintained by the server), or for other reasons
          (e.g. collection deleted, then recreated, access control changes,
          etc...). [3.2]
    
    That is *way* under-specified. If you get into the nonsense of "the server can
    invalidate the token whenever it feels like it", you will have a completely non-
    interopable system. The server needs to have reasonable expectations of the kind
    of cache it needs to keep, and the client needs to have reasonable expectations
    of what a server is required to do. At least one of those expectations MUST be
    that the act of using a token and getting a new one does not in itself
    invalidate the old one.
    
    I am willing to clear this DISCUSS if I am told that the consensus in the WebDAV
    community is that this sort of random server behavior has always been acceptable
    to the community, but I would prefer if the spec was tightened to give more
    guidance to implementers. 
        
  7. Pete Resnick: Comment [2012-01-03]:
    The security consideration is really a performance consideration. Though it can
    be used for nefarious DoS attacks, it can also be used by legitimate though
    stupid clients. I don't think it belongs in security considerations.

draft-gregorio-uritemplate

  1. Ron Bonica: Comment [2012-01-02]:
    Please run the nit-checker over this document. It appears to have a couple of
    unused references.
  2. Wesley Eddy: Comment [2012-01-02]:
    This seems to be a very useful and well-written document.
    
  3. Adrian Farrel: Comment [2011-12-31]:
    I have no objection to the publication of this document as a Standards
    Track RFC. I have a few very minor comments you might look at.
    
    ---
    
    You may note that you use RFC 2119 language in Section 1.1 but do not
    include the explanation until Section 1.5.
    
    ---
    
    Should you provide references for WSDL, WADL, and OpenSearch in section
    1.3?
    
    ---
    
    In section 1.5 there is a minor notational discrepency.
    
    You have:
    
         ALPHA          =  %x41-5A / %x61-7A   ; A-Z / a-z
         DIGIT          =  %x30-39             ; 0-9
         HEXDIG         =  DIGIT / "A" / "B" / "C" / "D" / "E" / "F"
    
    That means that HEXDIG has a mixed mode of hex notation and quoted
    letters. It might have made more sense to write...
    
         HEXDIG         =  DIGIT / %x41-46     ; 0-F
    
    But I struggle to see this as in any way an important comment! Maybe
    more interesting is to check that you really intended to exclude lower
    case alpha from the representation of hex numbers used in pct encoding.
    
    ---
    
    While Appendix A begins with a helpful note that the body of the
    document is normative text, it doesn't actually comment on whether the
    appendix is normative or not. It would be nice to make this explicit.
  4. Stephen Farrell: Comment [2011-12-30]:
    - End of p12 says "If a value provided by a user" which implies that
    all the usual injection attacks need to be countered in at least some
    deployments. Why doesn't that need to be mentioned in the security
    considerations? I don't think 3986 envisages that kind of issue. (Esp.
    if templates were combined with OAuth v1 or something else that
    authenticates the URL after expansion, meaning that the user at the
    browser could not have produced the URL herself.)
    
    - Can expressions be nested?, e.g. "{foo{bar}baz}" 1st sentence of 3.2
    implies not, but in any case it might be worth adding a sentence
    saying that nesting like that is not supported.
    
    - Expressions can be obfuscated. That could provide a new attack
    vector: expression author convinces webmaster that template is safe
    when its not. Not sure if that's worth a mention or not.
    
    - Seven operators; lists of variable with optional modifiers (esp
    "explode") - that all seems to me like too much to be universally
    useful and safe. Just an opinion, not a discuss.
    
  5. Russ Housley: Discuss [2012-01-03]:
        
      The Gen-ART Review by Vijay Gurbani on 1-Jan-2012 raised two minor
      issues.  I have not seen a response to this review, but I believe
      it deserves a response.  The two issues are repeated below.
    
      - S3.2.1, first paragraph: "A variable defined as an associative
      array of (name, value) pairs is considered undefined if the
      array contains zero members or if all member names in the array
      have undefined values."
    
      Here, do you mean "if all member names in the array have no
      values."?  That is, "undefined values" implies that values are
      present in the template, but are not understood.  On the other
      hand, "no values" implies the absence of any values at all.  In my
      reading of the text, it appears that "no values" conveys more
      context than "undefined values".
    
      - S4, general comment: I am not sure where the template expansion is
      done --- at the client (browser) or at the origin server (the draft
      does not enunciate this, and if it does, I may have missed it).  If
      the expansion is done at the origin server, I suspect that one can
      keep it a bit more busy by asking it to perform unnecessary
      template expansion for a resource that may be accessed normally
      even without template expansion.  Is it worth documenting this at
      all in the Security Considerations section?  (Clearly, if the expansion
      is done at the client, then it is the client incurring the expense
      of expansion.  Insofar as the client is malicious, it is best to
      let it expend as much effort as necessary.)
     
        
  6. Pete Resnick: Comment [2012-01-04]:
    2.2: I'm not clear from what is said in section 3 or Appendix A what happens
    when an op-reserve appears in a template that is being processed where the
    processor doesn't recognize these operators, in particular '$', '(', and ')'.
    Are they all treated as error conditions? If so, where in the algorithm.
    
    2.3: Do you really want varnames to be able to end with "." or "_" or begin with
    "_" or pct-encoded? If you want only internal ".", then you want:
    
    varname = varchar *(["."] varchar)
    
    If you only want internal "_" and pct-encoded as well, then:
    
    varname = ALPHA / DIGIT *(["_" / "." / pct-encoded] / ALPHA / DIGIT)
    
    I don't care, but the current construct (can't begin with ".", but otherwise
    anything goes) seemed like an odd choice.
    
    2.4.1: An upper limit on max-length might be a useful addition.
    
    3.2.1: The current text says:
    
       ...If the value
       contains multibyte UTF-8, care must be taken to avoid splitting the
       value in mid-character: count each Unicode codepoint as one
       character.
    
    The admonition in 1.6 seems equally useful for the values variables: Though they
    might exist as encoded, all contents of variables are assumed by the spec to be
    Unicodes, and must be appeneded by UTF-8ing them and pct-encoding as necessary.
    I think it's worth adding text on this.

draft-ietf-sipclf-problem-statement

  1. Jari Arkko: Comment [2012-01-05]:
    I think we need a log file format. And it needs to work on application level,
    because, as noted, layer 3 or 4 security makes it impractical to read off the
    contents of SIP messages.
    
    I'm less convinced about the specific proposal here. The text on wireshark for
    instance seems to indicate some lack of information on various logging
    mechanisms in the Internet. (Wireshark is just a tool that operates on the more
    general pcap http://en.wikipedia.org/wiki/Pcap interface.)
    
    I would guess that there are multiple needs in this space. One is for detailed
    SIP message logging for debugging and statistics purposes. For that purpose, a
    pcap-like recording of exact messages at the application layer might be more
    appropriate. Another need is for more high-level, CDR/billing/high-level
    statistics collection type of needs. There some summary of SIP events would be
    more appropriate. This would not necessarily record every message, and could
    even record some non-message events such as when the SIP entity gives up on
    trying to contact someone. The current design seems to be some mixture of these
    two kinds of approaches.
  2. Stewart Bryant: Discuss [2012-01-03]:
        I would like to discuss with the authors whether the data model is an example or
    is definitive? If it is definitive why is it in an informational draft, and
    indeed why is it not in an IANA registry?
    
    If it is not definitive, then please can this be made clearer in the document. 
        
  3. Ralph Droms: Discuss [2012-01-03]:
        The exact purpose and intended use of this document is not clear to
    me.  The document name include "problem-statement," the title includes
    "Framework and Data Model," and the abstract concludes with the
    sentence:
    
       We propose a common log file format
       for SIP servers that can be used uniformly by user agents, proxies,
       registrars, redirect servers as well as back-to-back user agents.
    
    I don't know if the text in section 4 is referring to the standards
    track CLF as defined in this document or an hypothetical CLF to be
    defined based on the problem statement in section 3 and the data model
    in section 8.  In fact, it seems that section 8 defines something more
    than just a data model, as it defines mandatory elements in CLF
    records, etc.
    
    The document needs a clear statement about whether or not it is
    defining the operational abstraction for the standards CLF.  If it is
    defining that standards CLF, it needs to be a standards track document.
     
        
  4. Ralph Droms: Comment [2012-01-03]:
    Editorial observation: "CLF format" is redundant.
    
    Process comment - the IESG Writeup Working Group Summary consists of
    one sentence: "The problem statement was not contentious."  I can't
    tell if this sentence refers to just the problem statement in section
    3 or the entire document.  I note that the document name includes
    "problem-statement" while the title includes "Framework and Data
    Model."  Perhaps the goals and purposes of the document changed during
    its development?  It would be helpful if the Working Group Summary gave
    more detail about the background, development and purpose of the
    document.
    
    Niggling irritation - the first couple of motivations listed in
    section 6 are relevant to the development of a CLF.  The remainder
    don't actually depend on a CLF; a CLF might ease the development of
    solutions to those problems.
    
    Which representation format is used in the example in section 9.1, or
    is the example an abstract representation independent of any specific
    format like the one defined in draft-ietf-sipclf-format-03?
  5. Wesley Eddy: Comment [2012-01-04]:
    I support Stephen & Ralph's DISCUSS points
  6. Adrian Farrel: Comment [2012-01-02]:
    Although this document does not define a CLF for SIP, I am not clear why
    the data model here is not normative as a Standards Track document.
    
    ---
    
    I wonder if you could consider adding to Section 7 a discussion of the
    migration / backward-compatiblity issues. Maybe these are no worse than
    today, but it will certainly be the case that a log file will need to
    contain some indication that it is in the CLF.
  7. Stephen Farrell: Discuss [2011-12-31]:
        This seems like a lot more than a problem statement.  I'm not clear
    whether the security and privacy considerations here will be relied
    upon in the format spec or not.  At present, -05 of the format
    draft says that this document says all that needs to be said, which
    is not something with which I agree. So, for now, I'm treating the
    security considerations here as those that will be provided as the
    final output of the sipclf WG. (Were this only a problem statement
    then that'd not be the case.)
    
    #1 While this document might not be able to say how files are to be
    protected, both locally and in transit, it could easily, and IMO,
    should, state requirements for that using 2119 MUSTs and also
    include some examples of how to meet those, e.g.  REQUIRE mutual
    authentication, confidentiality and integrity for transfers with
    the example that use of mutual auth TLS between nodes accomplishes
    this. (Note: I'd be fine if this were instead handled in the format
    document since that's I guess what most coders will read.)
    
    #2 IP src&dest and SIP to&from are mandatory - that's not very
    privacy friendly. Did the WG consider this? Did the WG consider
    defining an additional (less sensitive, more easily shared) format
    where those are obfuscated (but so as to still allow correlation?)
    If so, why wasn't that adopted? If not, doesn't that warrant
    consideration? (As-is sharing CLF files is likely to be tricky from
    at least an EU data protection p-o-v if there are some cross-border
    nodes involved.)
     
        
  8. Stephen Farrell: Comment [2011-12-31]:
    - What does "trace a call from one entity to another mean"?  I do
    hope we're not proposing that lawful intercept is the primary
    reason for this work. 
    
    - You say a few things the CLF is not at the end of section 4,
    would it be reasonable to add "The SIP CLF is not a tool for
    supporting lawful intercept."
    
    - Public access to the log is worse than network sniffing in at
    least two respects - log access trumps TLS and also network 
    sniffing is more restricted in time and place (topology).
  9. David Harrington: Discuss [2012-01-04]:
        1) I agree with the other IESG members who think this exceeds the scope of a
    problem statement.
    
    2) I agree with the DISCUSS that the shepherd writeup is lacking in useful
    detail. In my opinion this writeup is woefully inadequate to reflect the nature
    of the discussions that occurred, some contentious.
    
    3) The document fails to include any summary of WG discussions of using existing
    IETF protocols.
    
    There was significant contention in the WG about whether existing IETF standard
    data modeling languages, such as syslog structured data elements [RFC 5424] or
    ipfix Information Elements [RFC5655] could have been used for SIP logging. If
    this document is going to discuss why Apache CLF and Wireshark do not meet
    sipclf needs, which I believe it should, then the document should also explain
    the WG considerations for using syslog, ipfix, and psamp data models for SIP
    logging. This gap between existing standards and the problems prompting a new
    sipclf approach should be documented as part of the problem space.
    
    There was contention about whether the logging should be designed only for
    logging locally, or for local use and for being transported between systems. The
    WG discussed the need for secure transport of logged information. Existing
    standards already address this, e.g. syslog/TLS [RFC5425] and ipfix RFC5101].
    This should be documented as part of the problem space.
    
    The WG debated whether pre-filtering was a desirable feature, to control log
    growth rates, and bandwidth needed for transporting logs, and whether existing
    standards could be utilized for this purpose (ipfix offers a template approach
    that controls what data gets logged, and what data gets transported). This
    should be documented as part of the problem space.
    
    4) The document describes wireshark as inappropriate because the wireshark
    libraries would need to have sipclf functionality implemented across multiple
    OSes and configurations. But the proposed solution seems to be to develop a
    whole new format, so any tools for parsing this new format would need to be
    developed from scratch, across multiple OSes and configurations. That strikes me
    as an odd problem statement to justify a new sipclf approach.
    
    5) I support the Discusses about whether the sipclf mandatory fields in section
    8 is normative. If this is not normative, then RFC2119 language is probably
    inappropriate. If it is normative, then it belongs in a standards track
    document.
    
    6) Security considerations discusses the threats associated with stored logs.
    Existing standards for logging include capabilities for signing logs and
    detecting deletions and modifications [RFC5848], whether at rest or in transit.
    The potential need to secure logs at rest and in transit is part of the problem
    with logging SIP, and should be documented as part of the problem space. 
        
  10. David Harrington: Comment [2012-01-04]:
    1) section 6 strikes me as marketing claims for the wonderful things that a
    sipclf can provide. But these tools are not part of the scope of sipclf
    development. I question whether these claims of tools that could be developed
    really is part of a problem statement.
    
    2) RFC 3444 describes the difference between Information models and Data models.
    If section 8 is not a normative data model, then it should probably be called an
    Information model, rather than a data model.
  11. Pete Resnick: Comment [2012-01-04]:
    Seems like others have the DISCUSS points well in hand.
    
    It seems a bit goofy in section 8.1 to call out fields as "mandatory" and even
    say that they are "minimal information that MUST appear in any SIP CLF record",
    and then go on in section 9 to point out for some items: "When a given mandatory
    field is not applicable to a SIP entity, we use the horizontal dash ("-") to
    represent it." That would make the field pretty clearly non-mandatory.
  12. Dan Romascanu: Comment [2012-01-04]:
    In the 'Operational guidance' section: 
    
    > SIP CLF log files will take up substantive amount of disk space
       depending on traffic volume at a processing entity and the amount of
       information being logged.  As such, any enterprise using SIP CLF
       should establish operational procedures for file rollovers as
       appropriate to the needs of the organization.
    
    I suggest to replace the word 'enterprise' with 'organization'. The issue is
    certainly present in all type of networks, not only in enterprise deployment as
    it may be mis-understood here.
  13. Peter Saint-Andre: Discuss [2012-01-04]:
        I'd like to chat about internationalization. Section 8 mentions draft-ietf-
    sipclf-format as an example of a representation format that provides an ASCII-
    based encoding scheme. Are there any examples of encoding schemes that allow
    code points outside the ASCII range? More generally, what are the
    internationalization requirements for SIP logging? The requirements might be
    "none" if SIP messages cannot contain, say, UTF-8 encoded Unicode characters,
    but if so then it would be best for the specification to make that explicit. 
        
  14. Peter Saint-Andre: Comment [2012-01-04]:
    The document states that the Wireshark format cannot be used because "if the SIP
    messages are exchanged over a TLS-oriented transport, Wireshark will be unable
    to decrypt them and render them as individual SIP headers." Is there a reason
    why SIP servers cannot use the Wireshark *format* as a CLF even if they cannot
    use the Wireshark *application* on the data sent over an encrypted channel?
    
    A true nit: there is no such thing as "12:00 PM".
    
    Another nit: I have never seen "pend" as a verb. I suggest "can be in a pending
    state" or somesuch.
    
    When talking about URIs in Section 8, an informational reference to RFC 3986
    would be appropriate.
    
    The allowable values for the Message type field are 'R' (for Request) and 'r'
    (for response). Is it really a good idea to use values that differ only by case?
    (Also, the Directionality field has a value of 'r' -- another source of possible
    confusion; you might consider "o" and "i" for outbound and inbound instead of
    "s" and "r" for sent and received.)

draft-ietf-rtgwg-lfa-applicability

  1. Jari Arkko: Comment [2012-01-05]:
    Nice doc!
  2. Wesley Eddy: Comment [2012-01-02]:
    In Section 3.8, under "Intra Area Destinations", the Node Protection evaluations
    use "Full" rather than "yes", which is inconsistent with the explanation of
    terms at the beginning of the section and with the terms used for the next
    subsection for "Inter Area Destinations".
  3. Adrian Farrel: Comment [2012-01-04]:
    I have cleared my Discuss and moved to a Yes ballot.
    
    Thanks for addressing some of my comments.
    
    I still wish the I-D would spend more time looking at the security (are rpf
    checks commonly used in the topologies that are discussed, and if so what will
    be done to improve security when rpf checks are disabled) and management (what
    will be the consequences for management of turning on LFAs in the topologies
    discussed). But I don't think this is a blocking concern.
    
    ---
    
    Section 2 starts with...
    
       In this document, we assume that all links to be protected are point-
       to-point.
    
    The introduction has not mentioned the need to protect any links (nor
    what the concept of a protected link is).
    
    ---
    
    ISIS and OSPF should have references in Section 2.
  4. Russ Housley: Comment [2012-01-05]:
      The Security Considerations say: " This document does not introduce
      any new security considerations."  I am sure this is true, but it
      does not really help the reader.  Please add a sentence pointing the
      reader to security considerations from IP/MPLS.
    
      The late Gen-ART Review by Suresh Krishnan on 4-Jan-2012 includes a
      good suggestion.  Suresh suggests:
    
      This draft needs an informative reference to RFC5286. Without this
      reference it is very difficult to get the context required to
      understand this draft. Please consider adding the reference.
  5. Peter Saint-Andre: Comment [2012-01-04]:
    Personally I found this document to be nearly impenetrable, but that's probably
    because the air is so thin up here at the application layer. :) I am balloting
    "No Objection" on the assumption that our Routing ADs have performed up to their
    usual high standard of excellence.

draft-arkko-ipv6-only-experience

  1. Adrian Farrel: Comment [2011-12-31]:
    Thank you for an informative and readable document.
    
    If you were to have time to provide some additional words about
    management (in addition to the brief paragraph in section 8) it would
    be enlightening.
    
    - What was the user's experience of performing manual configuration
      where necessary? Is it the same as for v4 or messier?
    
    - What was the user's experience of running diagnostic tools to
      determine configuration and connectivity problems? Are the tools up
      to the same standard as for v4?
  2. Stephen Farrell: Comment [2011-12-30]:
    Good to see stuff like this.
    
    general:
    
    - A timeline would help readers understand the level of effort, e.g. 
    if you could give dates for when stuff happened related to a specific
    user's home being added, or anything else that gives the right 
    flavour for the level of effort.
    
    - Some ascii art n/w diagrams would be nice if you've time.
    
    - Some version numbers (esp. for stuff that didn't work) would be good
    for someone reading tihs in a few years time or who wants to try
    replicate your results 
    
    - It'd be good if you added your wget scripts as an appendix or put 'em
    at some URL (again so folks can replicate) - 3rd last para of 6.2 seems
    to imply that'd be useful (and that matches my own experience too)
    
    - Is the DNS64/NAT64 setup you're recommending not more "wiretap"
    friendly than a currently typical IPv4 or dual-stack network where DNS
    and NAT are less coupled? Either way, that'd be worth noting I think in
    section 9.
    
    specific
    
    - be good to point out that you don't in general need to add new APs
    (3.1, 1st para)
    
    - saying it "becomes crucial" that you can find DNS servers doesn't
    explain why that's harder which may be worth saying (3.2 1st para)
    
    - s/a year and half/a year and a half/ (s4, 1st para)
    
    - You mention Ercisson and Skype (negatively in the latter case) but are
    coy about the mobile OSes (presumably IOS and Android). I'd say do one
    or the other.
    
    - s/only couple of times/only a couple of times/
    
    - 5.1 - expand RA on 1st use
    
    - s/result require/results require/ or /result requires/ in 5.4
    
    - which year is "next year" in section 8? s/next year/YYYY/
    
    - s/cleaned from/cleaned of/ IPv4 literals
    

draft-ohye-canonical-link-relation

  1. Stewart Bryant: Comment [2012-01-03]:
    I support Russ's discuss and wonder if "Canonical" is actually the correct term.
    Canonical normally implies a more precise equivalence than the author describes
    in the document. I think that the text is describing the preferred link
    relation.
  2. Wesley Eddy: Comment [2012-01-02]:
    In Section 5, the first and third recommendations may be very difficult to use
    practically for sites where the majority of content is generated dynamically.  I
    don't think this document makes clear/strong enough statements on how this
    would/could/should be used for dynamic versus static resources, however, I defer
    to the judgement of the ADs closer to this topic.
  3. Adrian Farrel: Comment [2012-01-03]:
    I cleared my Discuss after an exchange with the AD.
    
    ---
    
    Building on Brian's review in Russ's Discuss... 
    
    If URIs are identical there is surely no isse to designating one of them
    as preferred. They are the same, and selecting any one is the same as
    selecting any other.
    
    I suspect this is just loose language since it is obvious from the 
    content (versus the Abstract) that you mean that it is the identical
    nature of the content returned by URIs that is what you define as
    making the URIs identical.
    
    Maybe you could go over this with a pedant's eye?
    
    ---
    
    Section 3 contains some examples of "SHOULD NOT". The subsequent
    paragraphs got my hopes up by starting with "MAY", but actually they do 
    not address the exception cases of the "SHOULD NOT." Since you have 
    chosen "SHOULD NOT" rather than "MUST NOT", you need to explain the
    option for varying the rule.
    
    ---
    
    Section 5
    
       Before adding the canonical link relation, verification of the
       following is recommended:
    
    Is that "RECOMMENDED"?
  4. Stephen Farrell: Comment [2011-12-30]:
    - A non-compromised site might also well lie about which URI
    is "canonical" for various purposes.
    
  5. Russ Housley: Discuss [2011-12-31]:
        
      The Gen-ART Review by Brian Carpenter on 14-Dec=2011 raised one
      minor issue that deserves a response.  The review says:
    
      > The canonical link relation specifies the preferred URI from a set
      > of URIs that return identical or vastly similar content, ...
    
      I don't understand the phrase "vastly similar". I don't understand
      what algorithm tests for vast similarity. 
    
      The same applies to "extremely similar" in section 3 and "similar to"
      in section 5.  Also, "similar to" is weaker than "vastly similar" or
      "extremely similar"; so does section 5 intend to weaken the earlier
      text? It seems that exactly the same phrase should be used in each
      case (not just a vastly similar phrase).
    
      This doesn't matter so much when it's a human designating the
      canonical relation.  But it can only be a matter of time before code
      starts to do this (which page is canonical among a set of generated
      pages?). A vague word like "similar" turns this into an AI problem. 
        
  6. Robert Sparks: Comment [2012-01-04]:
    Please consider adding text explaining when a user might choose to go against
    the SHOULD NOTs in section 3.
    
    It might help to cast the  last 4 bullets in section 3 as requirements on
    maintaining the link relation, rather
    than just creating it. You might also make
    it clear whether transient errors are of concern in the 3rd bullet.
  7. Sean Turner: Comment [2012-01-02]:
    I too tripped over the concept of canonical being used in the same sentence as
    vastly/extremely similar; therefore, I support Russ' discuss.

draft-kucherawy-dkim-atps

  1. Adrian Farrel: Comment [2012-01-02]:
    Thank you for advancing this work as Experimental and for taking the time to
    describe the experimental process.
  2. Stephen Farrell: Comment [2012-01-01]:
    
        
  3. Russ Housley: Discuss [2012-01-03]:
        
      IANA suggests that the registry be created now, even if it will not
      be used for some time.  Thanks to Alexey Melnikov for asking the
      question in his Gen-ART Review. 
        
  4. Pete Resnick: Comment [2012-01-03]:
    1. "ATPS" is never expanded in the text before its use. Please do so in the
    intro.
    
    2. The ABNF for atps-query should put an upper limit of 63 for the number of
    BASE32 characters:
    
       atps-query = 1*63BASE32 %x2e.5f.61.74.70.73.2e domain-name
    
    3. Is there reason to believe that, in practice, the hashing is really needed?
    Do we really believe that the combination of the two domain names will exceed
    255 characters?
    
    4. Given that this is an experiment, is there any reason not to give this a go
    with a new DNS query type? (Yeah, yeah, I know. But I thought I'd ask.)
  5. Peter Saint-Andre: Comment [2012-01-04]:
    This is a fine document. It's especially helpful to describe how the experiment
    will be run.
    
    I have one small comment: please consider adding a brief sentence about
    internationalized domain names (IDNs). I realize that RFC 6376 specifies
    encoding of IDNs as A-labels, but it might be good to reinforce that message
    here, such as (in Section 4.2):
    
       "domain-name" and "key-h-tag-alg" are defined in [DKIM].  Note 
       that according to [DKIM] internationalized domain names are to be  
       encoded as A-labels, as described in Section 2.3 of [RFC5890].
    
    This would necessitate adding an informative reference to RFC 5890, if you
    decide to make such a change.

draft-amundsen-item-and-collection-link-relations

  1. Stewart Bryant: Comment [2012-01-03]:
    I agree with Adrian's comments
  2. Wesley Eddy: Comment [2012-01-02]:
    The usefulness of this was not really clear to me, and the references are either
    just webpages or works-in-progress, so it's unclear to me whether it's really
    in-use or will actually be used.  However, I'm not personally concerned with the
    tidiness of this registry and trust the judgement of the ADs closer to it.
  3. Adrian Farrel: Comment [2011-12-31]:
    I have no objection to the publication of this document as an RFC, but
    I have a couple of Comments you could look at along the way.
    
    ---
    
    I found it odd that this "specification" is Informational since it does
    define things.
    
    ---
    
    The RFC Editor will want you to remove the citation from the Abstract.
    If you are providing a revised version, please fix this.
    
    ---
                          
    I would have preferred you to explicitly name the registry in which you
    want new entries recorded.
  4. Stephen Farrell: Comment [2011-12-30]:
    Would it be worth saying whether both item and collection
    can occur in the same href?
    
  5. Russ Housley: Discuss [2012-01-03]:
        
      The Gen-ART Review by Mary Barnes on 2-Jan-2012 raised a
      point that deserves a document update:
     
      ID nits indicates that "You're using the IETF Trust Provisions'
      Section 6.b License Notice from 12 Sep 2009 rather than the newer
      Notice from 28 Dec 2009." 
        
  6. Sean Turner: Comment [2012-01-01]:
    For the secdir reviewer:
    
    s4: r/are not believed to/do not