IESG Narrative Minutes

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

Narrative scribe: Susan Hares and Richard Barnes (The scribe was sometimes uncertain who was speaking.)

Corrections from: Brian Haberman (6/11), Sean Turner (6/11), Benoit Claise (6/11), Barry Lieba (6/21) [V3]

1 Administrivia

  1. Roll Call (1134 EDT)[Amy]
  2. Bash the Agenda
  3. Approval of the Minutes of the past telechat

  4. Review of Action Items from last Telechat

2. Protocol Actions

2.1 WG Submissions

2.1.1 New Items

  1. Datagram Congestion Control Protocol (DCCP) Encapsulation for NAT Traversal (DCCP-UDP) (Proposed Standard)
    draft-ietf-dccp-udpencap-10
    Token: Wesley Eddy
    Note: Pasi Sarolahti (pasi.sarolahti@iki.fi) is the document shepherd.
    Discusses/comments (from ballot draft-ietf-dccp-udpencap):
    1. Stewart Bryant: Comment [2012-06-06]:
      "These fields identify the UDP ports on which the source and destination (respectively) of the packet are listening for incoming DCCP-UDP packets. The UDP port values do not identify the DCCP source and destination ports."
      I don't know if there is enough DCCP in the wild that any of the router vendors have implemented ECMP support for it, so the following comment may be moot.
      This encapsulation is going to trigger the use of UDP ECMP in place of DCCP ECMP, but without enough entropy in the packet header for ECMP to occur. Thus a service using this encapsulation will probably see worse performance from the routing layer than a service running a native transport.
      This probably deserves discussion in the document.
    2. Gonzalo Camarillo: Discuss [2012-06-07]:
      As pointed out by Robert as well, this draft had not been reviewed by the SDP directorate. Flemming has been kind enough to review the draft on a short notice. This is his review: http://www.ietf.org/mail-archive/web/mmusic/current/msg09365.html
      I have taken some of his comments as discuss-level comments and some as comment-level comments.
      1) Section 5.2 states: "If the "a=rtcp:" attribute [RFC3605] is used, then the signalled port is the DCCP port used for RTCP."
      I think this warrants further discussion. How will this work if non-consecutive ports are to be used for DCCP-UDP itself and how will this work if a middlebox looks at the "a=rtcp" attribute and assumes the currently defined behavior in RFC 3605, which would effectively provide it with the port information for the (UDP native) RTCP stream today ?
      2) Section 5.4 discusses how to negotiate DCCP-UDP versus native DCCP (DCCP-STD) and in particular considers only the use of ICE for this (with the details of the encoding "left for future study"). While this may be appropriate for the basic use of DCCP-UDP versus DCCP-STD, it is arguably not appropriate when it comes to negotiating different RTP profiles within each of these (which are defined in this draft). SDP Capability Negotiation would be more suitable for this, as described in RFC 5939 Section 3.7. At a minimum, a reference to that effect and those considerations should be provided.
    3. Gonzalo Camarillo: Comment [2012-06-07]:
      Section 3.8, 4th paragraph: s/a DCCP-UDP server must therefore/a DCCP-UDP MUST therefore/ ??
      Various instances of repeat words and a few spelling errors that should be caught by a spell-checker.
      Also:
      - Section 5.1, first paragraph: s/(from [RFC4566]:/(from [RFC4566]):/
      - Section 5.4, second paragraph: s/DCCPx/DCCP/
      - Section 6, last paragraph: s/A firewall than/A firewall that/
      - ICE-TCP is now RFC 6544
    4. Ralph Droms: Comment [2012-06-05]:
      My only comment is really a question: do we want to define a mechanism for working around IPv6 NAT, thereby perhaps passively encouraging the deployment of IPv6 NAT. I realize the mechanism in this document is completely protocol independent and the definition of its use on IPv6 costs essentially nothing.
    5. Adrian Farrel: Comment [2012-06-04]:
      Martin already found everything I found
    6. Stephen Farrell: Comment [2012-06-04]:
      - Isn't this really pretending that the need for a UDP encapsulation is "short-term"? Why is such pretense useful?
      - Along the same lines, is a "SHOULD prefer DCCP-STD" not going to lead to another happy-eyeballs problem to be solved later? (The 1st para of section 5 says the above, but 5.4 says that its ok to prefer DCCP-UDP where low connection setup time is important, which appears to be the exception that makes preferring DCCP-STD a SHOULD and not a MUST?)
      - So a portmapper-like thing like this is going to have a problem with DANE perhaps - has anyone thought that out? that is, what port should I use when I name the DANE TLSA record? I assume it ought be the DCCP destination port, and that any resulting DTLS session is with the process listening there and not the portmapper. But am I right? This could well be a topic for future study rather than someting to decide here. (Not sure.) But in any case, saying something might be useful.
      - I think section 6 could usefully say that a client MUST establish DTLS sessions with the listener on the DCCP port and not the UDP port.
      - typo: 3.4, s/A DCCP-UDP implementations MAY/ DCCP-UDP implementations MAY/
    7. Russ Housley: Comment [2012-06-01]:
      Please consider the editorial comments in the Gen-ART Review by Kathleen Moriarty on 25-May-2012.
    8. Barry Leiba: Comment [2012-06-05]:
      Substantive comments; these are non-blocking, but please consider them seriously, and feel free to chat with me about them:
      Ditto on "Update 5762", and on Stephen's DANE comment. Also...
      -- 3.8 -- In list item 2: "A DCCP endpoint MUST implement one of the two methods:"
      Does that mean *exactly one*, or might it implement both, using each in different circumstances? Regardless of the answer to that question, the 2119 MAYs in the two methods are wrong. If at least one of these MUST be implemented, then they are *not* both entirely optional (which is what MAY means). I suggest changing "MAY accept" and "MAY support" to "accept" and "supports", respectively, and changing "A DCCP server" to "The DCCP server" in both cases.
      Other comments; no need to respond to these. Take them or modify them as you please:
      -- Introduction --
      There's no need for the [RFC4340] citation *twice* in the first paragraph, and then once again in the second. The first citation will do for all three. I would also change that first citation to be this way: "The Datagram Congestion Control Protocol (DCCP) [RFC4340] is a transport-layer protocol that..."
      The same is true for the three [RFC5597] citations in the second paragraph, though the reference style (of which I'm not terribly fond, but nevermind) makes it matter less. Still, I might change the second and third instances to just say "RFC 5597", without making them citations.
      -- 3 -- "A DCCP implementation MAY allow services to be simultaneously offered over any or all combinations"
      Does this really need to be a 2119 MAY? Why on Earth?
      -- 5 -- "This is considered a scenario that has the potential to be an important use-case."
      That's double-talk. Please find a different way to say what you really mean.
      -- 5.1 --
      The second sentence is missing a closing paren. It also should probably have a citation for [RFC5234].
      -- 5.2 --
      Do you really want to cite RFC 4234?
      -- 6 --
      OLD: A firewall than interprets
      NEW: A firewall that interprets
    9. Pete Resnick: Comment [2012-06-06]:
      Please consider the comments from Carsten Bormann's review:
    10. Robert Sparks: Discuss [2012-06-05]:
      1) The requirement to only use a single UDP port when encapsulating DCCP that would have been on two ports (separate RTP and RTCP) at the end of section 4 seems to interact with the demultiplexing rules in section 3.8.
      The six-tuples there would look something like:
      
       Source IP, source UDP, source DCCP, Dest IP, dest UDP, dest DCCP  
      
      [    A     ,   udpa    ,   dccpa1   ,    B   ,  udpb   ,   dccpb1  ] for RTP
      
      [    A     ,   udpa    ,   dccpa2   ,    B   ,  udbp   ,   dccpb2  ] for RTCP
      
      

      Those have the same UDP 4-tuple, so any DCCP endpoint that implemented the first of the two methods in section 3.8 (end of page 9) would not allow whichever of those came second. The media stream would fail to work.
      2) Please clarify what "active 6-tuple" means. At what point does it become active? When does it become de-active? How much work is it for one application to tie up all the 6-tuples at a peer, at least for a given UDP 4-tuple?
      3) The second paragraph of section 3.8 may need clarification. Is the sentence that starts "Because of this," trying to say that other applications on the same host as a server listening on the default port should not use the default port as their source port?
      4) Why is the requirement in Section 3.7 (to follow the guidance of rfc4340 section 14) a SHOULD? What else would a a DCCP-UDP implementation do?
    11. Robert Sparks: Comment [2012-06-05]:
      I don't think this received an SDP directorate review so far (see http://www.ietf.org/iesg/directorate/sdp.html), though I think Colin did point this document out to MMUSIC. I don't anticipate any problems with the SDP defined here, but will try to get additional eyes on it quickly. Please request a review for future documents that add to SDP.
      Consider renaming section 5.4 to "possible negotiation mechanisms" or something similar
    12. Martin Stiemerling: Comment [2012-06-04]:
      Good document with some nits: ...
    13. Sean Turner: Discuss [2012-06-05]:
      This draft says: "DCCP-UDP provides all of the security risk-mitigation measures present in DCCP-STD, and also all of the security risks."
      But the draft doesn't say anything about an MTI security mechanism. If this is really based at NAT traversal, then you might want to say something about DTLS because DCCP points to IPsec, which is all kinds of fun to setup to traverse NATS. Or is there some other mechanism that should be the MTI?
      If DTLS is invoked, then how does all that affect firewalls that intercept the messages?

    Telechat:

  2. The DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS) Protocol: TLSA (Proposed Standard)
    draft-ietf-dane-protocol-21
    Token: Stephen Farrell
    Note: Warren Kumari (warren@kumari.net) is acting as the Document Shepherd.
    Discusses/comments (from ballot draft-ietf-dane-protocol):
    1. Russ Housley: Discuss [2012-06-06]:
      Please add a description of Full Certificate to Section 2.1.2. I suggest: "Using the Certificate binary structure defined in [RFC5280]."
      Based on the briefing in the SAAG Session at IETF 83, I strongly suggest that this text be removed from Section 6.
      "At the time this is written, it is expected that there will be a new family of hash algorithms called SHA-3 within the next few years. It is expected that some of the SHA-3 algorithms will be mandatory and/or recommended for TLSA records after the algorithms are fully defined. At that time, this specification will be updated."
    2. Russ Housley: Comment [2012-06-06]:
      Section 1.3 says: "This document only applies to PKIX [RFC5280] certificates, not certificates of other formats. Later updates to this document might specify how to use certificates in other formats."
      I suggest that the second sentence be deleted. Neither the TLS charter nor the DANE charter calls for support of new certificate formats.
      An informative reference to define "SSL proxy" would be very helpful.
    3. Barry Leiba: Comment [2012-06-06]:
      Substantive comments; these are non-blocking, but please consider them seriously, and feel free to chat with me about them:
      -- 1.2, last paragraph -- "This document only relates to securely associating certificates for TLS and DTLS with host names; other security protocols are handled in other documents."
      This makes it sound like there are other documents related to DANE for things like IPsec and SSH. They're about keys in DNS in general, and the next sentence refers to non-DANE stuff. Then the last sentence comes back to TLS/DTLS.
      I suggest doing this paragraph as two paragraphs, this way:
      Sentence 1. Sentence 2. Sentence 5.
      Sentence 3. Sentence 4.
      And then re-phrase the new second paragraph to say something like, "...retrieving certificates from DNS for other protocols is handled in other documents."
      -- 1.3 -- "The DNSSEC signature needs to be validated on all responses that use DNSSEC in order to assure the proof of origin of the data."
      Don't *all* responses need to use DNSSEC, as well? Or is it possible to have a mixture of DNSSEC and unsecured DNS responses? Maybe it would be better to say it this way?:
      NEW: The DNSSEC signature needs to be validated on all DNS responses in order to assure the proof of origin of the data.
      -- 2.2 -- [in three places] "MUST be represented as an 8-bit unsigned decimal integer."
      What does "decimal integer" mean? I presume you should just take the word "decimal" out in all three places. Or is there something I'm missing?
      -- 2.3 --
      The order here is odd: you haven't introduced the _443 and _tcp things yet, but you're showing them in the examples. Maybe that's OK, but it feels a little confusing to me. Consider moving the examples after Section 3 (to a new Section 4).
      -- 4.1 -- "If the DNSSEC validation state on the response to the request for the TLSA RRset is bogus, this MUST cause TLS not to be started"
      Clearly, "bogus" is a technical term that means something distinct from "indeterminate or insecure" (in the next bullet). Alas, I cut class the day they explained "bogus", and so I need an explanation. Can you help? (I can't explain why I didn't think about this when I reviewed -14; sorry.)
      Thus, in order to achieve any security benefit from certificate usage 0 or 1, an application that sends a request for TLSA records needs to get either a valid signed response containing TLSA records or verification that the domain is insecure or indeterminate."
      There you define two criteria:
      1. Get a valid signed response containing TLSA records.
      2. Get verification that the domain is insecure or indeterminate.
      "If a request for a TLSA record does not meet one of those two criteria but the application continues with the TLS handshake anyway, the application has gotten no benefit from TLSA and should not make any internal or external indication that TLSA was applied."
      What indication might it make? Are we just talking about audit logs of some sort? In a user application, who will know or care about any indication that TLSA was applied?
      In any case, this sentence seems to say that the application can get neither of (1) or (2), and yet still continue with the TLS handshake. It's advised not to set an indication that it's using TLSA, but that's not a MUST, and anyway it can go ahead with the handshake in any case.
      "If an application has a configuration setting for turning on TLSA use, or has any indication that TLSA is in use (regardless of whether or not this is configurable), that application MUST not start a TLS connection or abort a TLS handshake if either of the two criteria above are not met."
      That sentence confuses me, for a couple of reasons. It seems contradictory to the prior sentence. If you didn't get what you expect...
      a. It says that if you have a configuration setting for TLSA, whether or not the setting is enabled, you have to abort. I don't think that's what you mean.
      b. It says that if you ignored the advice above and set your indication anyway, you MUST NOT [if you keep this, you need caps on the "not"] do stuff. But the previous sentence said you could go ahead anyway.
      c. The scope of the MUST NOT is wrong: it appears to say that you MUST NOT abort the TLS handshake, and I'm sure you don't mean that.
      d. If *either* of the two are not met? You mean if *both* are not met, because getting either is OK (and they're mutually exclusive). Right?
      -- 8.3 -- "For this reason, it is RECOMMENDED that DNSSEC validation always be performed on-host, even when a secure path to an external validator is available."
      I found this odd, because at several earlier points you talked about using an external validator with a secure path, and this is the first mention that it's not advisable. Please consider a reference to this section the first time you talk about that option (Sec 1.3), possibly in 4.1 after the bullet list, and also in Appendix A.3.
      Other comments; no need to respond to these. Take them or modify them as you please:
      (four items)
    4. Pete Resnick: Comment [2012-06-06]:
      In general, I find section 3 wrongheaded. I think it was a poor design choice to use _port._protocol.rest.of.name. But a poor design choice is not a reason for a DISCUSS. However, I do think that the document should make *some* attempt to justify this poor design choice. Perhaps it's not a poor design choice at all and I'm all wet. But I'd like to hear an explanation. Section 1 says (emphasis mine, excerpted):
      "TLS uses certificates to bind keys and *names*.
      "The public CA model upon which TLS has depended is fundamentally vulnerable because it allows any of these CAs to issue a certificate for any *domain name*.
      "The DNS Security Extensions (DNSSEC) provides a similar model that involves trusted keys signing the information for untrusted keys. However, DNSSEC provides three significant improvements. Keys are tied to *names in the Domain Name System (DNS)*, rather than to arbitrary identifying strings; this is more convenient for Internet protocols. Signed keys for any domain are accessible online through a straightforward query using the standard DNSSEC protocol, so there is no problem distributing the signed keys. Most significantly, the keys associated with a *domain name* can only be signed by a key associated with the parent of that *domain name*; for example, the keys for "example.com" can only be signed by the keys for "com", and the keys for "com" can only be signed by the DNS root. This prevents an untrustworthy signer from compromising anyone's keys except those in their *own subdomains*.
      "DNS-Based Authentication of Named Entities (DANE) offers the option to use the DNSSEC infrastructure to store and sign keys and certificates that are used by TLS. DANE is envisioned as a preferable basis for binding public keys to *DNS names*, because the entities that vouch for the binding of public key data to *DNS names* are the same entities responsible for managing the *DNS names* in question."
      Nowhere does it say that any legacy use of the CA model, nor any designed use of the DANE model, is about anything but a biding between keys and *domain names*. Yet section 3 goes on to add the additional design requirement that I use a port *and* a transport to identify the TLSA record I'm looking for. That prevents me from having a single TLSA record for "www.example.com", which I suspect will be the widest use case, unless I try to do crazy things with wildcards or DNAMEs (and all of their associated pain) as described in Appendix A. There was a requirement in 6394 that "DANE should be able to support multiple application services with different credentials on the same named host, distinguished by port number", but nowhere does that say that it has to be done on the lookup side. (For example, it could be that multiple TLSA records exist for "www.example.com", but they are distinguishable from the data returned. If data size was the problem, you could have had the TLSA records point to a record that actually contained the cert data.) And nowhere does 6394 say that multiple *transports* is a requirement. Note that 6394 also gives wildcard use as a requirement, but that is barely met by this document in that I can't wildcard "all names", but rather I must create subdomains of "_tcp.example.com" and "_udp.example.com" and "_sctp.example.com" and put wildcards under there. Even then, that does not allow me to wildcard all possible transports which I currently don't know about.
      So I think this was a terrible design choice. I don't think it reasonably satisfies the requirements of 6394. But a design choice it is. I do ask that you add some text justifying that design choice.

    Telechat:

  3. Definition of the Opus Audio Codec (Proposed Standard)
    draft-ietf-codec-opus-14
    Token: Robert Sparks
    Note: Jonathan Rosenberg (jdrosen@jdrosen.net) is the document shepherd.
    IPR: Broadcom Corporation's Statement about IPR related to draft-ietf-codec-opus-00 and draft-ietf-codec-description-00 (1)
    IPR: Xiph.Org Foundation's Statement about IPR related to draft-ietf-codec-opus-00
    IPR: Broadcom Corporation's Statement about IPR related to draft-ietf-codec-opus-00 and draft-ietf-codec-description-00 (2)
    IPR: Qualcomm Incorporated's Statement about IPR related to draft-ietf-codec-opus-05
    IPR: Xiph.Org Foundation's Statement about IPR related to draft-ietf-codec-opus-05
    IPR: Skype Limited's Statement about IPR related to draft-ietf-codec-opus-05
    IPR: Broadcom Corporation's Statement about IPR related to draft-ietf-codec-opus-05
    IPR: Skype Limited's Statement about IPR related to draft-ietf-codec-opus-07
    IPR: Microsoft Corporation's Statement about IPR related to draft-ietf-codec-opus-10
    IPR: Huawei Technologies Co.,Ltd's Statement about IPR related to draft-ietf-codec-opus-11 (1)
    IPR: Huawei Technologies Co.,Ltd's Statement about IPR related to draft-ietf-codec-opus-11 (2)
    Discusses/comments (from ballot draft-ietf-codec-opus):
    1. Stewart Bryant: Discuss [2012-06-07]:
      At this stage the authors do not need to do anything. I wish to discuss the following with my IETF collegues and will update this discuss accordingly.
      Given that the IETF knows of IPR claims and is publishing the software package as part of an RFC, I am concerned that we have an obligation to have included in the copyright notice a pointer to those IPR claims, lest at some point in the future the IETF are accused of failing to warn implementers of those claims.
      This may be something that needs clarifying with IETF council.
    2. Stewart Bryant: Comment [2012-06-07]:
      I am saddened that the IETF failed to meet the following goal for this work, i.e. to address the following:
      "There exist codecs that are standardized, but that cannot be widely implemented and easily distributed; according to reports, the presence of various usage restrictions (e.g., in the form of requirements to pay royalty fees, obtain a license, enter into a business agreement, or meet other special conditions imposed by a patent holder) has hindered adoptions of such codecs in interactive Internet applications."
    3. Ralph Droms: Comment [2012-06-06]:
      Is FEC really an accurate title for the mechanism described in section 2.1.7?
    4. Wesley Eddy: Comment [2012-06-06]:
      (non-blocking comments for the AD and editors)
      reference [Burg] has nothing but an author and title; it has to be locatable somehow other than google
      wikipedia references should be replaced by an actual textbook or other materials, in my opinion
    5. Adrian Farrel: Comment [2012-06-04]:
      I am balloting No Objection on this document on the basis that it has no impact on the internet's routing infrastructure, and that the WG and ADs have done a substantive review
      Per the Apps Dir review by Claudio Allocchio, I like the idea of adding a note (IESG Note?) to this document to highlight and make an exception of the use of code as a specification language.
    6. Stephen Farrell: Discuss [2012-06-06]:
      p20 says you MUST zero out padding bits. I wondered if there are any situations where so many zero'd padding bits would be sent and where the bits are being stream-enciphered that that'd create a problem. Dodgy stream-cipher setups have been seen in the wild in the past so this could in such a case be a real problem. One could say that these padding bits MUST be random or MUST be set to zero except when a stream cipher is used in which case they MUST be set randomly. While neither seems perfect, either would be better than exposing a key. You can't tell from the ciphertext if there's a covert channel in any case, so zero'ing the padding bits is no help to any intermediary once they're sent with confidentiality. If this is a potential problem, it'd be good to know how often padding might happen and if there's any way to force it to happen by manipulating the channel. Perhaps the best thing to do here is change the MUST to a SHOULD and document the potential problem in the security considerations section.
    7. Stephen Farrell: Comment [2012-06-06]:
      (five items plus nits)
    8. Brian Haberman: Comment [2012-06-06]:
      I support both Pete's and Sean's DISCUSS issues.
      I will also add that the instructions for extracting the source code does not work on a Mac running OS X 10.7.4. The base64 utility present in OS X generates an unrecognizable archive format that cannot be decompressed by tar.
    9. Barry Leiba: Comment [2012-06-05]:
      Substantive comments; these are non-blocking, but please consider them seriously, and feel free to chat with me about them:
      -- 1.1.3 -- "clamp(lo,x,hi) = max(lo,min(x,hi)) With this definition, if lo > hi, the lower bound is the one that is enforced."
      I'm not sure I understand what that text means. Are you saying that if, for example, you write "clamp(5,x,2)", it means the same as "clamp(2,x,5)" ? If that's the case, then maybe it should be defined as this:
      "clamp(a,x,b) = max(min(a,b),min(x,(max(a,b)))"
      In any case, please re-phrase the text to make clearer what you mean.
      -- 4.4 --
      Have packet loss and clock drift been modelled, and have the recommendations in 4.4 and 4.4.1 thus been validated? There seems to be a lot of speculation there, and I wonder how much basis in real experimentation there is.
      ======== Other comments; no need to respond to these: ...
    10. Pete Resnick: Discuss [2012-06-06]:
      Examining the source files and some of the other files, I find things similar to this:
      "Copyright (c) 2011 Xiph.Org Foundation, Skype Limited"
      I think the copyright for the source code should all be held by the IETF Trust with appropriate template information. The reason I am concerned that this might take a while is that in at least the case of the COPYING file in the root directory, the copyright is held by several organizations and individuals. I believe all of those folks must be contacted and explicitly agree to allowing their code to also be copyright by the IETF Trust.
      (The files in the git repository cited in the document probably also should have the IETF Trust copyright. Moreover, I would prefer to see the repository hosted on an IETF site rather than on github. I am concerned about drift of the code on github from the code in the RFC and ending up in a situation where the github version is -- de facto -- the place to go for the standard.)
    11. Pete Resnick: Comment [2012-06-06]:
      Like others, I don't feel I can give a substantive review to much of this document and will simply trust that it has gotten sufficient review. The one technical thing I noticed: A few variables that need to be unsigned because they're used in shift right (>>) operations are not explicitly specified as unsigned, in particular ft (used in 4.1.5) and b0 (used in 4.1.1). You do note other variables as unsigned, so I took these as omissions, but it may be clear from context. It seems to me a review of such variables might be useful.
      Like other ADs, I have some concerns about the use of source code for the normative spec:
      - First of all, this does turn the entire concept of "independent interoperable implementations" on its head. If the source code is normative, I don't see how we could ever judge that an implementation was independent and therefore how this spec would be advanced along the standards track.
      - Furthermore, I've got some concerns that we may, at some point in the future, encounter a small edge case where the code simply has a bug, but the text of the document makes it clear what the intention was. I would hate for us to say, "Well, the code is the normative reference, so the bug must stand and we must update the descriptive text to suit." I doubt that would happen, but we are in unchartered waters by using source as the normative spec.
      - Finally, the source code here is in base64, compressed, tarred format. It is completely unreadable in the spec. I do not know of any other RFC that has humanly-unreadable text in it. Again, we are in completely unchartered waters.
      And it is these "unchartered waters" that are the real issue all around. We may need to discuss how we handle this document now and in the future. But we signed up for this in the charter, so I'm willing to see it play out. There is no doubt that this document is an entirely odd duck.
    12. Martin Stiemerling: Comment [2012-06-05]:
      A nit: ...
    13. Sean Turner: Discuss [2012-06-05]:
      Updated ...
      I haven't complete my review (this one is a beast), but I thought I'd start the process rolling:
      1) If we're going to be distributing source code:
      Can we include a sha1/sha256 checksums or something in the Appendix? It's pretty common to do so when distributing source code.
      Could we also include the output of the idsigcheck code (https://tools.ietf.org/tools/idsigcheck/code) and place that somewhere permanent to make sure the contents haven't been doctored (and we're not distributing a virus).
      2) I glossed right over the pointer to the RFC in the previous paragraph. cleared this one...
      3) (right out of my league here and I'm sure there was some discussion about this) There's also a file called copying - shouldn't it include the following:
      Copyright (c) <insert year> IETF Trust and the persons identified as authors of the code. All rights reserved.
      and shouldn't it be in all the .h, .c, etc. files?
      4) (right out of my league here and I'm sure there was some discussion about this) Some of the copyright years in the .h files are farther back the readme. opus_types goes back to 1994. Does the readme need to cover all the dates?
    14. Sean Turner: Comment [2012-06-05]:
      The following command in the appendix don't work:
      "cat draft-ietf-codec-opus.txt | grep '^\ \ \ ###' | sed -e 's/...###//' | base64 -d > opus_source.tar.gz"
      I think you need to r/draft-ietf-codec-opus.txt/rfcXXXX.txt and note that the RFC editor should update this when it's published.

    Telechat:

  4. The Generalized TTL Security Mechanism (GTSM) for Label Distribution Protocol (LDP) (Proposed Standard)
    draft-ietf-mpls-ldp-gtsm-08
    Token: Adrian Farrel
    Note: Loa Andersson is the document shepherd (loa@pi.nu).
    Discusses/comments (from ballot draft-ietf-mpls-ldp-gtsm):
    1. Stephen Farrell: Comment [2012-06-05]:
      (1) 5082 has a MUST for authentication if negotiating GSTM. I don't get why this "built-in" negotiation, which seems to me to be added post-facto, gets around this need for strong authentication. I'm not going to insist that you define such authentication, (be nice if someone did though), but I do think you need to say you're not adhering to the MUST from 5082.
      (2) When receiving an LDP Link Hello with G=1, what checks are to be made on the TTL for that packet? If you don't enforce GSTM on that, then presumably attacks could be mounted with a Link Hello that has G=0, defeating the negotiation (hence point (1) above I guess;-). Why is this ok? If you're really taking a "leap of faith" here, then that's probably fine, but should be stated IMO. In any case I think you need to be clear about whether the TTL on this packet needs checking or not.
      nits: ...
    2. Barry Leiba: Comment [2012-06-05]:
      Substantive comments; these are non-blocking, but please consider them seriously, and feel free to chat with me about them:
      -- 2.1 -- "The G flag is meaningful only if the T flag is set to 0 (which must be the case for Basic Discovery), otherwise, the value of G flag SHOULD be ignored on receipt."
      What happens if it isn't? SHOULD means, basically, MUST unless you fully understand the consequences... so what are the consequences, so that an implementor might have a chance to understand them?
      ======== Other comments; no need to respond to these. Take them or modify them as you please: ...
    3. Sean Turner: Discuss [2012-06-05]:
      RFC 5082 says there's a MUST for authentication but doesn't say what mechanism - and that's fine. LDP's authentication mechanism, TCP-MD5, must be a configurable option (i.e., not always used). Doesn't using GSTM with LDP invoke a requirement to *use* the authentication mechanism (i.e., upgrade from a configurable option)?

    Telechat:

  5. TRILL (Transparent Interconnetion of Lots of Links): Bidirectional Forwarding Detection (BFD) Support (Proposed Standard)
    draft-ietf-trill-rbridge-bfd-06
    Token: Ralph Droms
    Note: Erik Nordmark (nordmark@acm.org) is the document shepherd.
    Discusses/comments (from ballot draft-ietf-trill-rbridge-bfd):
    1. Stewart Bryant: Discuss [2012-06-06]:
      This is I believe comparing the TRILL case with MPLS-TP
      "TRILL BFD uses the TRILL Rbridge Channel [TRILLChannel] similar to the way that MPLS OAM protocols use the MPLS Generic Associated Channel [RFC5586]. However, the RBridges that implement TRILL are IS-IS [IS-IS] based routers, not label switched routers; thus TRILL BFD is closer to IPv4/IPv6 BFD than to MPLS BFD."
      It is unclear what the above statement means. Whilst TRILL uses ISIS and MPLS-TP does not, the fundamentals high speed detection is is common to all. Where TRILL and MPLS-TP are closer than that are to the IP case is that neither have the use of IP addresses available to them.
    2. Stewart Bryant: Comment [2012-06-06]:
      I am surprised that TRILL did not take the opportunity to profile out the echo mode, since I understand that it is rarely used in IP networks and not used in MPLS_TP networks.
    3. Ralph Droms: Comment [2012-05-25]:
      From the shepherd writeup:
      There are references to section 10 and section 4, which should both be references to section 7.
    4. Adrian Farrel: Discuss [2012-06-06]:
      John Scudder raised a number of concerns in his Routing Directorate review. I support these in my Discuss as follows.
      1. It is not clear why demand mode was explicitly excluded. TRILL would actually seem to be a reasonable fit for demand mode.
      Please either include demand mode, or a short note on why it is excluded.
      2. "there will be only a single TRILL BFD Control session between two RBridges over a given interface visible to TRILL."
      This text is a little hard to parse and may be ambiguous. Please find a way to re-write it with reference to a pair of RBridges RB1 and RB2 and their interfaces RB1_Int1 and RB2_Int1. Or something like that.
      3. "the entire TRILL BFD Echo protocol specific data area is considered opaque and left to the discretion of the originating RBridge. Nevertheless, it is RECOMMENDED that this data include information by which the originating RBridge can authenticate the returned BFD Echo frame and confirm the neighbor that echoed the frame back."
      The use of "RECOMMENDED" contradicts "left to the discretion of" because "RECOMMENDED" is a very strong encouragement to do something. I think you need "suggested" as this is just general advice to an implementation.
      4. In two places text like the following appears:
      "Is the M-bit in the TRILL Header non-zero? If so, discard the frame. TRILL support of multi-destination BFD Echo is beyond the scope of this document."
      If multi-destination doesn't make sense in the context of TRILL, it is fine to exclude it by enforcing that the M-bit be zero. However, "beyond the scope of this document" normally means something like "we may do it in the future but haven't worked it out yet". By forcing the discard under these conditions you are doing more than putting the function out of scope: you are disabling it.
      You might solve this by mandating the setting of the bit to zero, and saying that if the bit is non-zero the behavior is future description, and that an implementation MAY discard the packet.
      5. The Security Considerations section specifies how authentication is to be done, but doesn't provide an analysis of it or of any broader issues. According to RFC 3552 (Section 5) the Security Considerations section should include an analysis of issues that arise from the operation of the protocol defined in the rest of the document, including but not limited to the security features of that protocol.
      You could place the current text in a subsection of the Security Considerations (called "Authentication") and add more text to the core section.
      Additionally, I think you are missing a normative reference to https://datatracker.ietf.org/doc/draft-ietf-trill-rbridge-oam/ This is necessary to set the context for why you are using BFD and for what purpose. It would also clarify which BFD features are needed and what OAM features (from the whole set) are addressed by BFD.
      Finally, although I understand that the scope of this document is limited to encapsulation, I think that this leaves the solution deficient. It needs a description of bootstrapping in the Trill environment.
    5. Adrian Farrel: Comment [2012-06-06]:
      It is very odd to bring this document forward ahead of the normatively referenced draft-ietf-trill-rbridge-channel
      Doing this makes the review less certain.
    6. Stephen Farrell: Comment [2012-06-05]:
      - I'm not clear if the key derivations described in section 6 are mandatory to implement or not. It says that if IS-IS auth is in effect, then you "use" (would that be better with a 2119 MUST?) BDF Meticulous Keyed SHA1 (nice name btw:-), but its not clear to me if that means this is MTI or not.
      - What does "that state of IS-IS shared secret" mean? Maybe s/that state//?
      - I don't get why this only needs/uses key ID 0, can you explain further? I guess I'd have expected that if the IS-IS-shared-key had a key ID, then that would be used for the derived key(s) defined here.
      - I'm wondering if the authentication scheme described here is really used or not? I think it'd be good to say if its real or fictional, if that is known.
    7. Brian Haberman: Comment [2012-06-04]:
      Thank you for addressing my DISCUSS so quickly.
    8. Barry Leiba: Comment [2012-06-05]:
      Minor comments; no need to respond: I find citing nroff in the Acknowledgments section to be odd, for whatever that's worth. (I also can't remember when I last saw an actual normative reference to ASCII.)
    9. Robert Sparks: Comment [2012-06-06]:
      I agree with the shepherd's recommendation to change the reference for [ASCII] to ANSI X3.4. I suggest looking at the references in RFC5891 for an example: ...
    10. Martin Stiemerling: Discuss [2012-06-04]:
      I wonder if what is said about congestion control in Section 7 of RFC 5880 is also applicable to this draft.
      The current draft text denies this, as it states in Section 5: "It is up to the operator of an RBridge campus to configure the rates at which TRILL BFD frames are transmitted on a link to avoid congestion (e.g., link, I/O, CPU) and false failure detection."
      This seems to be absolutely contradicting RFC 5880 on the matter of congestion control.
    11. Sean Turner: Discuss [2012-06-06]:
      s6 contains the following: "If such IS-IS authentication is in effect then, unless configured otherwise, TRILL BFD Control frames sent between those RBridges use BFD Meticulous Keyed SHA1 authentication [RFC5880] with keying material derived as shown below"
      I think you need to say what the MTI is in this case. That might be as simple as adding "MUST" before "use" but that's a little more than MTI that's mandatory to use. Are you trying to say that in this case, BFD Meticulous Keyed SHA1 authentication [RFC5880] with keying material derived as shown below MUST be supported as a configurable option: ey [material derivation here]?

    Telechat:

  6. Clarifications and Implementation Notes for DNSSECbis (Proposed Standard)
    draft-ietf-dnsext-dnssec-bis-updates-18
    Token: Ralph Droms
    Note: Andrew Sullivan (ajs@anvilwalrusden.com) is the document shepherd.
    Discusses/comments (from ballot draft-ietf-dnsext-dnssec-bis-updates):
    1. Stephen Farrell: Comment [2012-06-05]:
      During the "no answer" mega-discussion on the DANE list, [1] I seem to recall this comment was made more than once: "you're seeing all this because you're maybe the first new application that really needs DNSSEC," or words to that effect. Should any of that discussion be reflected in this document? (I assume its not already there for timing reasons if nothing else.)
    2. Russ Housley: Discuss [2012-06-01]:
      The Gen-ART Review by Richard Barnes on 25-May-2012 raised two major concerns... Building on this review, I have these suggestions:
      (1) Section 4.1: Please clarify the threat model. If the zone operator is malicious, then it can simulate the necessary zone cut and still prove the non-existence of records in the child zone.
      (2) Section 5.10: Please explain why the "Accept Any Success" policy is more preferable the "Highest Signer" policy. This analysis might not appear in Section 5.10; it could appear in an appendix.
    3. Barry Leiba: Comment [2012-06-05]:
      Substantive comments; these are non-blocking, but please consider them seriously, and feel free to chat with me about them:
      Ditto Sean's comments about DNSSEC vs DNSSECbis, and about Draft Standard -> Internet Standard.
      -- 2.1 -- "signal that a zone MAY be using NSEC3, rather than NSEC."
      This MAY and the one in the following paragraph are misused: they should not be 2119 terms. Describing what a zone "may be using" is simply a descriptive phrase, not anything normative. Actually, I would say "might be using".
      -- 5.2 --
      Isn't the point really more general: that if the validator is unable to validate the signature, *for whatever reason*, it treats the zone as unsigned? Wouldn't it be better to make that general point clear... and then give unknown or unsupported key or message digest algorithms as reasons it would be unable to validate?
      ======== Other comments; no need to respond to these. Take them or modify them as you please: ...
    4. Robert Sparks: Comment [2012-06-05]:
      Is there a reference that could be added to section 3.1 to where the scaling concerns called out there are discussed?
    5. Sean Turner: Comment [2012-05-25]:
      These are my preliminary sets of comments:
      1) Any reason you can't just refer to DNSSECbis as DNSSEC? I guess does the outside world know DNSSECbis isn't DNSSEC?
      2) General: r/RFCXXXX/[RFCXXXX] throughout except for the abstract. A couple of times I thought the RFC references needed to be included in [] so it's probably better to just do it everywhere. You also need to add [RFC2308] as a reference.
      3) s1 paragraph two: RFC 6410 got rid of Draft Standard so either r/Draft/Internet or r/from Proposed Standard to Draft Standard/along the Internet Standards track. Or something like that.
      4) s1.2: To cut down on the possible "where is X defined" you could add something like: "Readers are assumed to be familiar with DNSSECbis documents as the terminology used herein comes from those documents."
      5) s2, s2.1, s2.2: Could you replace the three instances of "should {also} be" with "are"? If the WG considers them part of the core, then aren't they? It also avoids the whole question about whether it ought to be SHOULD (not that I'm asking to change that).
      6) s2.1: Pet peeve requirements in a paragraph that starts with Note. Couldn't you just r/Note that the/The
      7) s5.5: Might be worth pointing out that this was filed as an errata.
      8) s5.6, s5.7, and s5.10: I was already to give you the kudos for each section being clear about which document was being updated until I got to these sections. Please state which RFC you're updating in these sections. In s5.6 is it updating 3225?
      9) s5.11: could you just strike "note that"

    Telechat:

  7. TRILL: Header Extension (Proposed Standard)
    draft-ietf-trill-rbridge-extension-04
    Token: Ralph Droms
    Note: Erik Nordmark (nordmark@acm.org) is the document shepherd.
    Discusses/comments (from ballot draft-ietf-trill-rbridge-extension):
    1. Ronald Bonica: Discuss [2012-06-06]:
      Could you provide use-cases for this extension mechanism? What extensions do you intend to define? How do these extensions fit into your current charter?
    2. Wesley Eddy: Comment [2012-06-04]:
      I had questions that overlapped a subset of Adrian's COMMENT, so would encourage the authors and AD to pay attention to his ballot.
    3. Adrian Farrel: Comment [2012-06-04]:
      I have no objection to the publication of this document. I have a number of questions and issues you might want to look at before the document is published as an RFC.
      Does this document update 6325?
      Abstract say... "This document specifies an initial extension providing additional flag bits and specifies two of those bits."
      The Introduction says... "This document specifies an initial extension providing additional flag bits and specifies one of those bits."
      Anyway, it appears you define the meaning of three bits (if you include CRSVS). And, through the definition of the structure, you sort of define the meaning of the others.
      If there is an indication that at least one CHbH option present, does each hop have to scan all options to check whether they are relevant? This seems to be a compounding factor for the note in Section 2.
      The note is good, but I wonder what the consequences is of an increased likelihood of dropping a packet with a hop-by-hop critical option.
      In section 2 "o flag affecting an as yet unspecified class of RBridges, for example border RBridges in a TRILL campus extended to support multi-level IS-IS"
      It seems odd that if the class of RBridges is unspecified, you can give an example like this. I suggest that you rebrand this flag as reserved for future extensions, or go to the trouble of defining its real use.
      The same ambiguity arises in the text describing CRSVS in 2.3.1
      BTW s/flag/flags/ ?
      Section 2 "if it is a known unicast frame"
      Are there unicast frames where it is impossible to know that they are unicast?
      Section 2.3
      [see link]
      The bracketed text is a little confusing. There are indeed only two summary bits defined in 6325. There is a third bit defined here. All three bits have been given an "S" suffix.
      Is section 2.4 simply egg sucking, or is there something else that needs to be explained?
    4. Stephen Farrell: Discuss [2012-06-05]:
      I don't understand the security model for the ingress-to-egress extensions. Given that hop-by-hop extensions can be modified/dropped, there can be no ingress-to-egress cryptographic security, however this is not stated. Were it stated, it would appear to make all extensions hop-by-hop, at least in terms of (non)end-to-end security. Either that or you need a quite complex set of security mechanisms, which I assume you don't want. Or, perhaps the WG were happy that introducing extensions like this, means never being able to use cryptographic security and extensions between ingress and egress? (Or some highly complex in-between state.) I'm not looking for any specific change for now, but rather just to understand what's the expectation here for e2e-like cryptographic security.
    5. Stephen Farrell: Comment [2012-06-05]:
      - Pure opinion from a TRILL-ignoramus: this seems over complex to me.
      - I don't get how the TLVs are encoded, and associated with the various flag fields, e.g. CItE etc. That may be "obvious" but I didn't get it at all sorry.
      - I don't get how extended flag thing is supposed to work. How is someone supposed to know when to allow addition of the bicycle extension?
      - This: "Any extended flag indicating a significant change in the structure or interpretation of later parts of the frame which, if the extended flag were ignored, could cause a failure of service or violation of security policy MUST be a critical extension. If such an extended flag affects any fields that transit RBridges will examine, it MUST be a hop-by-hop critical extended flag" seems like it'd be a fine source for useless rathole arguments.
      - What does: "A transit or egress RBridge may assume that the critical summary bits are correct." mean?
      - This seems very odd: "Conflicting extensions SHOULD NOT be defined, but if they are,..."
    6. Barry Leiba: Discuss [2012-06-05]:
      -- 5 -- Please explain (briefly -- a sentence or two will surely do) the reason for selecting Standards Action for this registry. I'd prefer it if that sentence or two were in the IANA Considerations, unless there's a reason not to put it there.
      I understand that there is a limited number of bits to be given out, so freely allocating them for the asking would be harmful. Still, Standards Action is very heavyweight: did you consider IETF Review (which could allow Informational or Experimental documents to do allocations, with community consensus and IESG approval), or even Specification Required (where you could give instructions that the designated expert exert tight control over the allocations)?
    7. Barry Leiba: Comment [2012-06-05]:
      What Adrian said....

    Telechat:

  8. Expert Review for IODEF Extensions in IANA XML Registry (Proposed Standard)
    draft-ietf-mile-iodef-xmlreg-01
    Token: Sean Turner
    Note: Kathleen Moriarty (Kathleen.Moriarty@emc.com) is the document shepherd.
    Discusses/comments (from ballot draft-ietf-mile-iodef-xmlreg):
    1. Benoit Claise: Comment [2012-06-05]:
      Section 1, Introduction "IODEF extensions via class extension through AdditionalData and RecordItem elements, as per section 5.2 of [RFC5070], generally register their namespaces and schemas with the IANA XML Namespace registry at ...
      => remove "generally"
      - There is one nit catched by the nit checker:
      => The draft header indicates that this document updates RFC5070, but the abstract doesn't seem to mention this, which it should.
    2. Russ Housley: Comment [2012-06-05]:
      Please consider the editorial comments in the Gen-ART Review by Suresh Krishnan on 5-Jun-2012.
    3. Pete Resnick: Discuss [2012-06-05]:
      This document defines no protocol, does not say how to implement a protocol, and does not have anything to do with a protocol except for information about how an IANA registry is to be used. Why is this going on the standards track? This should either be Informational, or more likely BCP.
    4. Robert Sparks: Comment [2012-06-05]:
      Consider "designated by the IESG" instead of "designated by the IETF Security Area Directors."

    Telechat:

2.1.2 Returning Items

  1. Definition of Managed Objects for the Neighborhood Discovery Protocol (Proposed Standard)
    draft-ietf-manet-nhdp-mib-14
    Token: Adrian Farrel
    Note: Stan Ratliff (sratliff@cisco.com) is the document shepherd.
    Discusses/comments (from ballot draft-ietf-manet-nhdp-mib):
    1. Ronald Bonica: Comment [2012-06-04]:
      This document fails to provide use cases. Because it doesn't provide use cases, it is not clear that any/all of its objects are useful.
      While this comment might be leveled concerning regarding MIB, it is particularly applicable in this case because we have so little operational experience with ad hoc networks. Will the ad hoc network include a NOC? What policy will that NOC attempt to enforce? What information/control will the NOC need to enforce that policy.
    2. Stewart Bryant: Comment [2012-05-23]:
      I am voting no objection on the basis that other members of the IESG who are more knowledgeable on MIBS will have reviewed this.
    3. Benoit Claise: Discuss [2012-06-06]:
      - There is a clear DISCUSS coming from the MIB-doctor review. Please address it.
      - While reading through the document, I've been really waiting for an applicability statement section. A sentence [RFC6130] such as "if router A is able to exchange packets with router B, and router B is able to exchange packets with router C, this does not guarantee that router A and router C can exchange packets directly" got me thinking about the management and operational aspects. How do you plan on using this MIB module, taking into account that you're dealing with an ad-hoc network?
      Note that the write-up mentions: "This document shepherd is not aware of existing implementations of this MIB although several implementers have indicated interest in the work." So the potential implementers should have some views on the following questions.
      I'm really after 3 different parts in the applicability statement (or call it use cases if you want to): configuration management, monitoring, and notification. And I have questions such as:
      * one static NMS or each MANET router configures/monitors his (newly attached) neighbor(s)?
      * where are the notifications sent to?
      * Do you expect all MANET routers to always have connectivity to a static NMS?
      * etc...
      Obviously, monitoring, for example, is important in ad-hoc networks, but please let us know how you envision doing this. For example, right now, I see the term "appropriate SNMP management stations", and I have no clue what's "appropriate" in the management of an ad-hoc network.
      I see some other MANET MIB modules...
      * draft-ietf-manet-olsrv2-mib-04 Definition of Managed Objects for the Optimized Link State Routing Protocol
      * draft-ietf-manet-report-mib-02 Definition of Managed Objects for Performance Reporting
      * draft-ietf-manet-smf-mib-04 Definition of Managed Objects for the Manet Simplified Multicast Framework Relay Set
      However, this document is the first MANET MIB module to reach the IESG, so those operational questions are important. If this is expressed in a different document, let me know, and I can review it.
      Along the same lines,
      1. see Al Morton's review, part of the OPS-DIR
      "General question: Is a lossy, mobile ad-hoc network compatible with SNMPv3? In other words, will the link performance information needed for troubleshooting really be available when it is needed most, and critical nodes may be unreachable?"
      2. Read Ron's Bonica's Abstain
    4. Benoit Claise: Comment [2012-06-06]:
      - Abstract: "This document defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes objects for configuring parameters of the Neighborhood Discovery Protocol (NHDP) process on a router."
      Should this be "MANET router"? "MANET router" is used in RFC6130 Alternatively, I see in this document:
      "NHDP router"
      "router in a Mobile Ad Hoc Network (MANET)"
      Same remark for the introduction, which uses the same text.
      - First occurence of NHDP must be expanded.
    5. Stephen Farrell: Comment [2012-05-21]:
      I agree with Sean's discuss. DES just isn't up to this these days.
      p60 - I think you mean confidentiality and not privacy?

    Telechat:

2.2 Individual Submissions

2.2.1 New Items

  1. Simple Mail Transfer Protocol extension for Message Transfer Priorities (Proposed Standard)
    draft-melnikov-smtp-priority-16
    Token: Pete Resnick
    Discusses/comments (from ballot draft-melnikov-smtp-priority):
    1. Stewart Bryant: Comment [2012-06-07]:
      I agree with Adrian's comments
    2. Wesley Eddy: Discuss [2012-06-05]:
      The document talks about end-to-end use across a mix of MTAs that do or do-not support the extensions, but not across MTAs with different administrators. The applicability of this mechanism would seem to apply only to a single "domain" of administration, where control of incoming messages at the edge can be performed to make sure the system isn't abused. I think the same problems from interdomain IP QoS apply here as the initial MTA where the priority was approved may not be able to tell if it will be approved all the way across the path of other MTAs to the destination.
      In the case where there are multiple MX records, I believe this document is only advocating continuing to use the record that was selected based on the RFC 5321 algorithm (using the specified record priority, or randomly within a single priority) and doesn't attempt to "balance load" across them. The assumption here must be that the network resource bottleneck is shared between this MTA and the multiple potential next-hops. If there's a situation where there isn't a shared bottleneck, however, this assumption will not lead to optimal behavior, and I think the topic should at least be touched upon and discussed somewhat.
    3. Wesley Eddy: Comment [2012-06-05]:
      I agree with Martin's DISCUSS point that in Section 5.1, "congestion" refers to existence of a queue at the application layer, and does not have anything to do with network-layer congestion which should probably be clarified.
    4. Adrian Farrel: Comment [2012-06-04]:
      I have no objection to the publication of this document.
      Are you sure you have not conflated priority and importance? High priority messages need to be delivered quickly and an implementation may want to let them overtake lower priority messages. High importance messages need to be delivered (eventually) and should have a lower chace of being dropped.
      4.1 with its ability to reject low priority messages appears to be doing importance.
      Appendix E gives some motivations for 19 priorities. It seems like a very large number to me. Experience with this sort of range of options and priority levels suggests that it only adds confusion. I suppose my question is: are you sure?
    5. Stephen Farrell: Comment [2012-06-05]:
      - (An almost "discuss"): 4.6 means that anyone who is ok to send me a prio=9 message can cause me to send a whole bunch of prio=9 messages (as DSNs). Is that not a new DoS vector? Please explain why not.
      (The rest are not near-discusses btw.)
      - The writeup is somewhat coy about the use-case. Its military messaging, ala STANAG 4406/ACP 123.
      - I don't get why the EHLO keyword has no parameters. I'd have thought that a parameter there could be a useful way to signal some semantics for MT-PRIORITY values. Maybe that was discussed before though. (I've not kept up with all the mail on this draft btw.)
      - I agree that the "untrusted source" concept in 4.1 seems broken and that a resolution such as that discussed via email seems right, that is, that this is down to bilateral agreement really rather than being tied to SMTP AUTH so directly.
      - Is 4.3 really needed? Seems like its not about relaying but is generally true.
      - What exactly does "retain" mean in 4.4? I guess it means that the MLA MUST forward the mail with the same MT-PRIORITY value to any next-hop that supports it. But what if only 50% of the next-hops for a given message support this?
      - I don't get what X.3.TBD2 means at the end of p7. (I even looked at 2034 and still don't get it.)
      - Saying its "important" for MUAs to support this spec seems over-stated. If you want to keep the term "important" then I guess it'd be good to specify to whom what is important? (Not all players in this space have commensurate interests.)
      - 5.1, possible nit, possible significant comment. A lower priority message could be sent first with advantage to all. If e.g. the sending MTA knows that sending the higher priority message over a later, but "better", interface, e.g. that is currently down. This is a familiar concept when dealing with contacts in DTNs. I think maybe it'd be better to talk about trying to get the mail delievered earlier rather than the speciifics of how priorities map to sending things from queues.
    6. Brian Haberman: Comment [2012-06-04]:
      I agree with Adrian's comment that 19 priorities may be hard to manage.
    7. Robert Sparks: Discuss [2012-06-06]:
      1) There is some tension between the requirements in Sections 4.1 and 4.2 (highlighted by a requirement in Section 10).
      Section 4.1 says "The SMTP server MAY also alter the message priority (to lower or to raise it) in order to enforce some other site policy."
      Section 10 reinforces that MTAs "MAY override the priority values"
      But Section 4.2 to take the results of 4.1 (which includes the possibility of changing the message priority), but goes on to say:
      "For example, once an MTA accepts a message, the MTA MUST NOT change a (syntactically valid) priority value if that value is not supported (as a distinct priority value) by the MTA's implementation of this extension."
      This appears to be a conflict. Would it better capture the intent to change that last sentence to sat "only because that value is not supported" instead of "if that value is not supported"? If so, I suggest rewriting the sentence without using the 2119 MUST NOT. Would the following work? (Adam Roach put this together):
      "An MTA that supports the MT-PRIORITY extension MUST include an MT-PRIORITY parameter whenever it relays a message to an MTA or MDA that also supports the MT-PRIORITY extension. The MTA sets the value of the MT-PRIORITY parameter according to its local policy. In the absence of a policy-based reason for adjusting the value, the MTA SHOULD set the MT-PRIORITY parameter to the value determined from the procedure described in section 4.1. Note that this value might be different than the priority level at which the MTA actually handles the request, due to the rounding described in section 5."
      Section 5 also reiterates this MUST and might need to be adjusted to match.
      2) Amplifying Stephen's almost-discuss: Do we really want to preempt real messages in favor of DSNs? If so, are there security considerations specific to DSNs that this document should point to (that would discuss how to mitigate large numbers of malicious DSNs)?
      3) Section 5.4 restricts MTAs from rejecting messages based on priority or priority+size (arguing that only MSAs should do so). Why is this particular kind of rejection being treated differently than other kinds of rejections at MTAs? Is there a general requirement to avoid these bounces in another document you can point to instead? If not, a discussion of the tradeoffs of a policy that would result in a rejection seems more appropriate than a normative restriction to not reject.
      4) What discourages an MUA (the UA, not the user) that gets a rejection stating that its priority was too low from immediately resubmitting the request with a higher priority? Is there anything that discourages a user from doing so?
      5) (The clarification the Transport ADs have asked for may obviate this). Can the document clarify why and when an MTA would want to open a new connection for sending higher priority messages? If it has a connection already, why wouldn't it just use that? If there's no transport congestion, and the queues behind the existing connection are backing up, how is opening a new connection going to help? If there _is_ transport congestion, opening a new connection is going to hurt.
    8. Martin Stiemerling: Discuss [2012-06-05]:
      I have a DISCUSS about this paragraph and the benefit of this mechanism:
      Section 5.1., paragraph 6: "This extension provides benefits in networks with limited available bandwidth or long round trip times, when the actual message transfer over the network can create a significant portion of the overall message delivery time from a sender to a recipient. It is also useful in case of a congestion, for example resulting from an MTA queue build-up. When neither of the two conditions mentioned above is true, the use of the MT-PRIORITY SMTP extension will not result in a better SMTP service."
      Congestion is there if the incoming rate is higher than the outgoing rate on a bottleneck. How does this mechanism help when there is congestion? This isn't clear to me at all.
      First of all, this seems to be talking about congestion on the SMTP level and not necessarily at the transport level. Please clarify this in the text.
      This mechanism can even increase the queue length at a MTA, if high priority messages arrive at the same rate (or even higher) than the outgoing rate from that MTA. This situation would also occur without the priority mechanism, but the mechanism can make the situation even worse for lower priority messages. The will be queued up and potentially starve to death in the queue, if higher priorty messages keep arriving and they are being jumped to the front or near front of the queue.
      I do not see that it is safe to state that this mechanism will help in congestion at the SMTP level.
      Further, how is the queue to be managed with the different priority levels?
    9. Martin Stiemerling: Comment [2012-06-05]:
      - I agree with Adrian about the really high number of priority levels
      - What do the priority level mean in a multi-domain scenario, i.e., two domains can have a completely different understanding about what a particular level means.
      - Section 6., paragraph 0: "Unextended SMTP does not offer a service for timely delivery. The "Deliver By SMTP Service Extension" (DELIVERBY Extension) defined in [RFC2852] is an example of an SMTP extension providing a service that can be used to implement such constraints. But note that use of the DELIVERBY extension alone does not guarantee any priority processing."
      Does this extension allow timely delivery? Or is it simply trying to enhance timely delivery? And what is timely delivery? I don't see how this is offering a service for timely delivery in all circumstances.
    10. Sean Turner: Discuss [2012-06-05]:
      Is it appropriate for the IETF to recommend the mappings for others (thinking here mostly about MMHS and NS/EP values) in App A and C? Seems like we ought to define the mechanism and then somebody representing those communities defines what values they want?
    11. Sean Turner: Comment [2012-06-06]:
      Updated #4 based on some IMs with Alexey:
      0) BTW - my initial thought about this draft was "I wish I had of thought of this ten yeas ago." Really hoped you'd go all the way and have different precedences/priorities for the to and cc recipients ;)
      1) App A: Actually ACP123/STANAG 4406 specifies a range from 0-31. And (this relates to the discuss) if somebody specifies four more values higher than override how will the mapping get done?
      2) App A: In 123/4406, there's priority and precedence. The values you list are from precedence so I assume you're talking about those values and not the urgent, routine, and non-urgent values for priority. App A says priority though:
      "Military Messaging as specified in ACP 123 [ACP123] (also specified in STANAG 4406 [STANAG-4406]) defines six priority values."
      3) App B contains the following: "Where SMTP is used to support military messaging, the following mappings SHOULD be used."
      Should this say mixer instead of military messaging?
      4) I'm trying to wrap my head around why if you go from MMHS to SMTP you'd map urgent and flash to different level but if you went through MIXER to get to SMTP you'd get flash and override mapped to the same level (urgent)
      And, what do you do if both primary-precedence and mixer priority are there?

    Telechat:

2.2.2 Returning Items

  1. (none)

3. Document Actions

3.1 WG Submissions

3.1.1 New Items

  1. The "about" URI Scheme (Informational)
    draft-ietf-appsawg-about-uri-scheme-06
    Token: Barry Leiba
    Note: Jiankang Yao (yaojk@cnnic.cn) is the Document Shepherd.
    Discusses/comments (from ballot draft-ietf-appsawg-about-uri-scheme):
    1. Adrian Farrel: Comment [2012-06-03]:
      I have no objection to the publication of this document as an Informaitonal RFC.
      Following on from the transition to Informational (for which, thanks), you might consider s/specifies/describes/ (But this is a *very* unimportant comment!)
    2. Stephen Farrell: Comment [2012-06-04]:
      The FCFS registration scheme could lead to anyone registering an about-token that's in current use in a browser. Why isn't expert review more suitable here to protect against such abuse? For example, nothing here prevents me from registering about:config, which is used by >1 browser. I don't get why that is not a problem. (This is almost a discuss btw, I'd really like to see a response if possible before the telechat.)
      Why does about-token "correspond" to hier-part from 3986? What would "about://example.com/foo/bar" mean? I'd have thought that omitting the authority would be correct for this scheme - why am I wrong?
    3. Brian Haberman: Comment [2012-05-16]:
      Just a non-blocking comment that can be resolved easily...
      The Acknowledgments section appears to be incomplete. The first sentence looks fragmented, maybe an editing mistake?
    4. Martin Stiemerling: Comment [2012-06-04]:
      no objection if this draft is really going for informational (as listed in the draft) and not as Standards Track as listed in the datatracker.
    5. Sean Turner: Comment [2012-06-05]:
      I have no objection to the publication of this document as an Informational RFC.

    Telechat:

  2. TCP Options and MSS (Informational)
    draft-ietf-tcpm-tcpmss-04
    Token: Wesley Eddy
    Note: The Document Shepherd is Michael Scharf (michael.scharf@alcatel-lucent.com).
    Discusses/comments (from ballot draft-ietf-tcpm-tcpmss):
    1. Benoit Claise: Comment [2012-06-06]:
      I don't understand what we gain by having this statement: "Additional clarification was sent to the TCP Large Windows mailing list in 1993 [Borman93]."
      The goal can't be to acknowledge the person who posted the email, as this is the author ;-) And it's even confusing. Should I review this email on the top of the document. This can't be, right?
      Note: that's the first time I see, part of a RFC, a reference to a specific email in the archive
    2. Adrian Farrel: Comment [2012-06-02]:
      I am surprised about the perceived need to update an obsoleted RFC, but if folk really want to do it, I think they should make it very clear in this document that RFC 2385 has been obsoleted by RFC 5925 so that readers understand that using RFC 2385 with the correction documented here is not the preferred approach.
      Would a reference to RFC 6151 help?
    3. Russ Housley: Comment [2012-06-01]:
      Please consider the editorial comments in the Gen-ART Review by Martin Thomson on 24-May-2012.
    4. Barry Leiba: Comment [2012-06-05]:
      Substantive comments; these are non-blocking, but please consider them seriously, and feel free to chat with me about them:
      In addition to Adrian's comment...
      -- 8 --
      At least RFC 879 and RFC 2385 should be normative references here. It's kind of hard to imagine how this can Update those, and not cite them normatively. (Don't make the mistake of thinking that Informational documents don't have normative references.)
    5. Martin Stiemerling: Comment [2012-06-04]:
      The abstracts seems to be rather short in order to give hints to a reader, i.e., it would be good to the part of IP options and TCP MSS from the into.
    6. Sean Turner: Comment [2012-06-05]:
      Just a reminder to publish a version that incorporates changes agreed to as part of the secdir review.

    Telechat:

  3. Guidelines for Defining Extensions to IODEF (Informational)
    draft-ietf-mile-template-04
    Token: Sean Turner
    Note: Kathleen Moriarty (Kathleen.Moriarty@emc.com) is the document shepherd.
    Discusses/comments (from ballot draft-ietf-mile-template):
    1. Benoit Claise: Discuss [2012-06-05]:
      Extending on Adrian's point: I would be glad if you discussed with the Ops ADs the need to include a section in Extensons I-Ds covering Manageability Considerations for the extensions.
      While I understand that not all extensions have management and operational considerations, a way forward could be a new manageability section that would contain something such as: "If an extension implies some operational and management considerations such as defined in RFC5706 appendix A, then those considerations must be covered in this section"
    2. Benoit Claise: Comment [2012-06-05]:
      - shouldn't you reference draft-ietf-mile-iodef-xmlreg-01?
      - section 2 "A non-exhaustive list of good candidate extensions to IODEF includes:"
      This sentence really looks like you're proposing new work. Could you change it to something such as "a few examples ..."
      - class extension through AdditionalData and RecordItem elements, as per section 5.2 of [RFC5070]
      s/and/or
      - section A.6 and A.7. It seems that you redo the RFC editor document here. This is confusing.
    3. Adrian Farrel: Comment [2012-06-01]:
      Thank you for this document I have no objeciton to its publication.
      Here are a few minor and non-blocking Comments that I would appreciate you reading before publication is complete.
      You will need to remove the citaiotn notation ([ ]) from the Abstract.
      You should clean up the unused reference to RFC 3339.
      I would be glad if you discussed with the Ops ADs the need to include a section in Extensons I-Ds covering Manageability Considerations for the extensions.
      I found the nesting of appendixes a little perturbing, but it is probably easy enough to grok.
    4. Russ Housley: Comment [2012-06-01]:
      Please consider the editorial comments in the Gen-ART Review by Peter Yee on 26-May-2012.
    5. Robert Sparks: Discuss [2012-06-05]:
      In a Last-Call discussion, the author agreed with a comment made by Peter Saint-Andre that the reference to RFC6545 should be informational, but that change has not yet been made.
      It should be made more obvious that the examples in Appendix B are examples, and not actual registrations. Using a real protocol for the example is hazardous. Could you replace the first example (ENUM) with something clearly not real? (btw, RFC6116 defines e164.arpa.)
      Can you provide a reference into the existing IODEF specifications for where the kind of extension discussed in item 3 of section 3 is anticipated?
    6. Robert Sparks: Comment [2012-06-05]:
      Peter's Last-Call comments also included some editorial suggestions. I would like to amplify his first comment on being very clear when the use of these templates (and the guidance around the selection of a namespace value) are appropriate.

    Telechat:

3.1.2 Returning Items

  1. (none)

3.2 Individual Submissions Via AD

3.2.1 New Items

  1. The application/zlib and application/gzip media types (Informational)
    draft-levine-application-gzip-03
    Token: Pete Resnick
    Discusses/comments (from ballot draft-levine-application-gzip):
    1. Adrian Farrel: Comment [2012-06-06]:
      I have no objection to the publication of this document.
      Please check zlib/Zlib/ZLIB for consistency
    2. Stephen Farrell: Comment [2012-06-06]:
      Are the contact points for these registrations ok? The template calls for a person/email address, but both give URLs: http://www.zlib.net/ and http://www.gzip.org which is fine information but perhaps not what's needed?
    3. Brian Haberman: Comment [2012-06-05]:
      I have no problem with the publication of this document. I have one editorial nit that you may take or leave as you see fit.
      - The cross referencing notation of "Section [blah]" is confusing given that it uses short-hand names for sections. Please consider changing these to "Section #" style notation.

    Telechat:

3.2.2 Returning Items

  1. (none)

3.3 IRTF and Independent Submission Stream Documents

3.3.1 New Items

  1. ARP Extension for ILNPv4 (Experimental)
    draft-irtf-rrg-ilnp-arp-06
    Token: Ralph Droms
    Note: Tony Li (tony.li@tony.li) is the document shepherd.
    Discusses/comments (from ballot draft-irtf-rrg-ilnp-arp):
    1. (none)

    Telechat:

3.3.2 Returning Items

  1. IPv4 Options for ILNPv4 (Experimental)
    draft-irtf-rrg-ilnp-v4opts-05
    Token: Ralph Droms
    Note: Tony Li (tony.li@tony.li) is the document shepherd.
    Discusses/comments (from ballot draft-irtf-rrg-ilnp-v4opts):
    1. Stewart Bryant: Comment [2012-05-31]:
      Thank you for addressing my discuss items.
      I would like to suggest that the authors verify that the IPv4 routers in their test network forward packets containing options with adequate performance before they invest significant time in the IPv4 Option approach.
    2. Ralph Droms: Comment [2012-05-30]:
      Thank you for publishing draft-irtf-rrg-ilnp-v4opts-05.txt, which revises the specification to use the IPv4 experimental option code.
      I have two minor editorial comments:
      In Figure 1, the option length fields should be "OL=20" and "OL=12".
      In Figure 3, the option length field should be "OL=12".
    3. Adrian Farrel: Comment [2012-05-23]:
      I agree with Stewart's Discuss stating that there is no need to allocate IPv4 options for this experiment since it can be run on existing experimental options.
      The authors give a reason why using the existing values would not meet their requirements. I dispute the reason as follows:
      "In order to experiment with a new protocol, an experimental value may be needed that won't collide with an existing or future usage."
      It is precisely the nature of experiments that they may colide if they are run in overlapping networks. There are sufficient code points available that this can be coordinated if there are multiple experiments. There are no existing experiments that immediately spring to mind. Future experiments will be less likely as IPv4 is sunsetted.
      The LISP documents (currently in the RFC Editor Queue for publication as Experimental RFCs in the IETF Stream) have clear and unambiguous text to caution the user about the unknown side-effects of conducting the experiment on the Internet. For example, draft-ietf-lisp-23 says:
      "This experimental specification has areas that require additional experience and measurement. It is NOT RECOMMENDED for deployment beyond experimental situations. Results of experimentation may lead to modifications and enhancements of protocol mechanisms defined in this document. See Section 15 for specific, known issues that are in need of further work during development, implementation, and experimentation."
      "An examination of the implications of LISP on Internet traffic, applications, routers, and security is for future study. This analysis will explain what role LISP can play in scalable routing and will also look at scalability and levels of state required for encapsulation, decapsulation, liveness, and so on."
      It seems to me highly desirable that similar caveats be applied to this work and added to the front of all ILNP documents. I strongly urge the authors and IRSG to apply such text.

    Telechat:

  2. ICMP Locator Update message for ILNPv4 (Experimental)
    draft-irtf-rrg-ilnp-icmpv4-05
    Token: Ralph Droms
    Note: Tony Li (tony.li@tony.li) is the document shepherd.
    Discusses/comments (from ballot draft-irtf-rrg-ilnp-icmpv4):
    1. Stewart Bryant: Comment [2012-05-31]:
      Thank you for addressing my concerns.
    2. Adrian Farrel: Comment [2012-05-30]:
      I have cleared my Discuss on the basis of the new revision to this document. Thanks to the authors for moving to an experimental code point for this work.
      The LISP documents (currently in the RFC Editor Queue for publication as Experimental RFCs in the IETF Stream) have clear and unambiguous text to caution the user about the unknown side-effects of conducting the experiment on the Internet. For example, draft-ietf-lisp-23 says:
      "This experimental specification has areas that require additional experience and measurement. It is NOT RECOMMENDED for deployment beyond experimental situations. Results of experimentation may lead to modifications and enhancements of protocol mechanisms defined in this document. See Section 15 for specific, known issues that are in need of further work during development, implementation, and experimentation."
      "An examination of the implications of LISP on Internet traffic, applications, routers, and security is for future study. This analysis will explain what role LISP can play in scalable routing and will also look at scalability and levels of state required for encapsulation, decapsulation, liveness, and so on."
      It seems to me highly desirable that similar caveats be applied to this work and added to the front of all ILNP documents. I strongly urge the authors and IRSG to apply such text.

    Telechat:

1254 EDT break

1300 EDT back

4 Working Group Actions

4.1 WG Creation

4.1.1 Proposed for IETF Review

  1. IMAP MOVE extension (imapmove)
    Token: Barry

    Telechat:

4.1.2 Proposed for Approval

  1. System for Cross-domain Identity Management (scim)
    Token: Barry

    Telechat:

4.2 WG Rechartering

4.2.1 Under evaluation for IETF Review

  1. TCP Maintenance and Minor Extensions (tcpm)
    Token: Wes

    Telechat:

4.2.2 Proposed for Approval

  1. Behavior Engineering for Hindrance Avoidance (behave)
    Token: Wes

    Telechat:

  2. Network File System Version 4 (nfsv4)
    Token: Martin

    Telechat: [9:10-9:12am]

  3. Multipath TCP (mptcp)
    Token: Wes

    Telechat:

5. IAB News We can use

6. Management Issues

  1. Draft IPv4 registry changes [IANA #576598] (Michelle Cotton)

    Telechat:

  2. Publication of the Tao (Russ Housley)

    Telechat:

  3. Protocol Number Request [IANA #501375] (Michelle Cotton)

    Telechat:

  4. Nomcom requirement

    Telechat:

  5. Note Well

    Telechat:

7. Agenda Working Group News

1425 EDT Adjourned


Valid HTML 4.01 Strict


Appendix: Snapshot of discusses/comments

(at 2012-06-07 07:30:13 PDT)

draft-ietf-dccp-udpencap

  1. Stewart Bryant: Comment [2012-06-06]:
    "These fields identify the UDP ports on which the source and
    
      destination (respectively) of the packet are listening for
    
      incoming DCCP-UDP packets.  The UDP port values do not identify
    
      the DCCP source and destination ports."
    
    
    
    I don't know if there is enough DCCP in the wild that any of the 
    
    router vendors have implemented ECMP support for it, so the 
    
    following comment may be moot. 
    
    
    
    This encapsulation is going to trigger the use of UDP ECMP in
    
    place of DCCP ECMP, but without enough entropy in the 
    
    packet header for ECMP to occur. Thus a service using
    
    this encapsulation will probably see worse performance from
    
    the routing layer than a service running a native transport.
    
    
    
    This probably deserves discussion in the document.
  2. Gonzalo Camarillo: Discuss [2012-06-07]:
    
    As pointed out by Robert as well, this draft had not been reviewed by the SDP
    
    directorate. Flemming has been kind enough to review the draft on a short
    
    notice. This is his review:
    
    
    
    http://www.ietf.org/mail-archive/web/mmusic/current/msg09365.html
    
    
    
    I have taken some of his comments as discuss-level comments and some as comment-
    
    level comments.
    
    
    
    1) Section 5.2 states:
    
    <quote>
    
       If the "a=rtcp:" attribute [RFC3605] is used,
    
    then the signalled port is the DCCP port used for RTCP.
    
    </quote
    
    I think this
    
    warrants further discussion. How will this work if non-consecutive ports are to
    
    be used for DCCP-UDP itself and how will this work if a middlebox looks at the
    
    "a=rtcp" attribute and assumes the currently defined behavior in RFC 3605, which
    
    would effectively provide it with the port information for the (UDP native) RTCP
    
    stream today ?
    
    
    
    2) Section 5.4 discusses how to negotiate DCCP-UDP versus native DCCP (DCCP-
    
    STD) and in particular considers only the use of ICE for this (with the details
    
    of the encoding "left for future study"). While this may be appropriate for the
    
    basic use of DCCP-UDP versus DCCP-STD, it is arguably not appropriate when it
    
    comes to negotiating different RTP profiles within each of these (which are
    
    defined in this draft). SDP Capability Negotiation would be more suitable for
    
    this, as described in RFC 5939 Section 3.7. At a minimum, a reference to that
    
    effect and those considerations should be provided.
    
    
  3. Gonzalo Camarillo: Comment [2012-06-07]:
    Section 3.8, 4th paragraph:
    
    s/a DCCP-UDP server must therefore/a DCCP-UDP MUST
    
    therefore/ ??
    
                                            
    
    Various instances of
    
    repeat words and a few spelling errors that should be caught by a spell-checker.
    
    
    
    Also:
    
    - Section 5.1, first paragraph:
    
    s/(from [RFC4566]:/(from [RFC4566]):/
    
                                      ^
    
    - Section 5.4, second paragraph
    
    s/DCCPx/DCCP/
    
    
    
    - Section 6, last paragraph:
    
    s/A firewall than/A firewall that/  
    
    
    
    - ICE-TCP is now RFC 6544
  4. Ralph Droms: Comment [2012-06-05]:
    My only comment is really a question: do we want to define a mechanism for
    
    working around IPv6 NAT, thereby perhaps passively encouraging the deployment of
    
    IPv6 NAT.  I realize the mechanism in this document is completely protocol
    
    independent and the definition of its use on IPv6 costs essentially nothing.
  5. Adrian Farrel: Comment [2012-06-04]:
    Martin already found everything I found
  6. Stephen Farrell: Comment [2012-06-04]:
    
    - Isn't this really pretending that the need for a UDP
    
    encapsulation is "short-term"? Why is such pretense useful? 
    
    
    
    - Along the same lines, is a "SHOULD prefer DCCP-STD" not going
    
    to lead to another happy-eyeballs problem to be solved later?
    
    (The 1st para of section 5 says the above, but 5.4 says that its
    
    ok to prefer DCCP-UDP where low connection setup time is
    
    important, which appears to be the exception that makes
    
    preferring DCCP-STD a SHOULD and not a MUST?)
    
    
    
    - So a portmapper-like thing like this is going to have a
    
    problem with DANE perhaps - has anyone thought that out? that
    
    is, what port should I use when I name the DANE TLSA record?  I
    
    assume it ought be the DCCP destination port, and that any
    
    resulting DTLS session is with the process listening there and
    
    not the portmapper. But am I right? This could well be a topic
    
    for future study rather than someting to decide here. (Not
    
    sure.) But in any case, saying something might be useful.
    
    
    
    - I think section 6 could usefully say that a client
    
    MUST establish DTLS sessions with the listener on the
    
    DCCP port and not the UDP port. 
    
    
    
    - typo: 3.4, s/A DCCP-UDP implementations MAY/ DCCP-UDP
    
    implementations MAY/
  7. Russ Housley: Comment [2012-06-01]:
    
      Please consider the editorial comments in the Gen-ART Review by
    
      Kathleen Moriarty on 25-May-2012.  Please find the review here:
    
      http://www.ietf.org/mail-archive/web/gen-art/current/msg07453.html
  8. Barry Leiba: Comment [2012-06-05]:
    Substantive comments; these are non-blocking, but please consider them
    
    seriously, and feel free to chat with me about them:
    
    
    
    Ditto on "Update 5762",  and on Stephen's DANE comment.  Also...
    
    
    
    -- 3.8 --
    
    In list item 2:
    
       A DCCP endpoint MUST implement one of the two
    
       methods:
    
    
    
    Does that mean *exactly one*, or might it implement both, using each in
    
    different circumstances?  Regardless of the answer to that question, the 2119
    
    MAYs in the two methods are wrong.  If at least one of these MUST be
    
    implemented, then they are *not* both entirely optional (which is what MAY
    
    means). I suggest changing "MAY accept" and "MAY support" to "accept" and
    
    "supports", respectively, and changing "A DCCP server" to "The DCCP server" in
    
    both cases.
    
    
    
    ========
    
    Other comments; no need to respond to these. Take them or modify them
    
    as you please:
    
    
    
    -- Introduction --
    
    There's no need for the [RFC4340] citation *twice* in the
    
    first paragraph, and then once again in the second.  The first citation will do
    
    for all three.  I would also change that first citation to be this way: "The
    
    Datagram Congestion Control Protocol (DCCP) [RFC4340] is a transport-layer
    
    protocol that..."
    
    
    
    The same is true for the three [RFC5597] citations in the second paragraph,
    
    though the reference style (of which I'm not terribly fond, but nevermind) makes
    
    it matter less.  Still, I might change the second and third instances to just
    
    say "RFC 5597", without making them citations.
    
    
    
    -- 3 --
    
       A DCCP implementation MAY allow services to be simultaneously offered
    
       over any or all combinations
    
    
    
    Does this really need to be a 2119 MAY?  Why on Earth?
    
    
    
    -- 5 --
    
       This is considered a
    
       scenario that has the potential to be an important use-case.
    
    
    
    That's double-talk.  Please find a different way to say what you really mean.
    
    
    
    -- 5.1 --
    
    The second sentence is missing a closing paren.  It also should
    
    probably have a citation for [RFC5234].
    
    
    
    -- 5.2 --
    
    Do you really want to cite RFC 4234?
    
    
    
    -- 6 --
    
    OLD
    
       A firewall than interprets
    
    NEW
    
       A firewall that interprets
  9. Pete Resnick: Comment [2012-06-06]:
    Please consider the comments from Carsten Bormann's review:
    
    
    
    http://www.ietf.org/mail-archive/web/apps-discuss/current/msg06038.html
  10. Robert Sparks: Discuss [2012-06-05]:
    
    1) The requirement to only use a single UDP port when encapsulating DCCP that
    
    would have been on two ports (separate RTP and RTCP) at the end of section 4
    
    seems to interact with the demultiplexing rules in section 3.8.
    
    
    
    The six-tuples there would look something like:
    
      Source IP, source UDP, source DCCP, Dest IP, dest UDP, dest DCCP  
    
    [    A     ,   udpa    ,   dccpa1   ,    B   ,  udpb   ,   dccpb1  ] for RTP
    
    [    A     ,   udpa    ,   dccpa2   ,    B   ,  udbp   ,   dccpb2  ] for RTCP
    
    
    
    Those have the same UDP 4-tuple, so any DCCP endpoint that implemented the
    
    first of the two methods in section 3.8 (end of page 9) would not allow
    
    whichever of those came second. The media stream would fail to work.
    
    
    
    2) Please clarify what "active 6-tuple" means. 
    
    At what point does it become
    
    active? When does it become de-active?
    
    How much work is it for one application
    
    to tie up all the 6-tuples at a peer, at least for a given UDP 4-tuple?
    
    
    
    3) The second paragraph of section 3.8 may need clarification. Is the sentence
    
    that starts "Because of this," trying to say that other applications on the same
    
    host as a server listening on the default port should not use the default port
    
    as their source port?
    
    
    
    4) Why is the requirement in Section 3.7 (to follow the guidance of rfc4340
    
    section 14) a SHOULD? What else would a a DCCP-UDP implementation do?
    
    
  11. Robert Sparks: Comment [2012-06-05]:
    I don't think this received an SDP directorate review so far (see
    
    http://www.ietf.org/iesg/directorate/sdp.html), though I think Colin did point
    
    this document out to MMUSIC. I don't anticipate any problems with the SDP
    
    defined here, but will try to get additional eyes on it quickly. Please request
    
    a review for future documents that add to SDP.
    
    
    
    Consider renaming section 5.4 to "possible negotiation mechanisms" or something
    
    similar
  12. Martin Stiemerling: Comment [2012-06-04]:
    Good document with some nits:
    
    
    
    - ID-Nits complains a bit about unused references and one obsoloted reference
    
      ** Obsolete normative reference: RFC 4234 (Obsoleted by RFC 5234)
    
    
    
    - the  document header should mention that this memo updates RFC 5762.
    
    
    
    - Section 3., paragraph 7:
    
    
    
    >    Section 3.8 describes usage of UDP ports.  This includes
    
    >    implementation of a DCCP-UDP encapsulation service as a daemon that
    
    >    listens on a well-known port, allowing multiplexing of different DCCP
    
    >    applications over the port.
    
    
    
      s/over the port/over the same port/
    
    
    
    - Section 5.4., paragraph 2:
    
    
    
    >    An approach to doing this might be to include candidates for the
    
    >    DCCP-UDP encapsulation and native DCCP into an Interactive
    
    >    Connectivity Establishment (ICE) [RFC5245] exchange.  Since DCCP is
    
    >    connection-oriented, these candidates would need to be encoded into
    
    >    ICE in a manner analogous to TCP candidates defined in [ICE-TCP].
    
    >    Both active and passive candidates could be supported for native
    
    >    DCCPx and DCCP-UDP encapsulation, as may DCCP simultaneous
    
    >    open[RFC5596].  In choosing local preference values, it may make
    
    >    sense to to prefer DCCP-UDP over native DCCP in cases where low
    
    >    connection setup time is important, and to prioritise native DCCP in
    
    >    cases where low overhead is preferred (on the assumption that DCCP-
    
    >    UDP is more likely to work through legacy NAT, but has higher
    
    >    overhead).
    
    
    
      s/DCCPx/DCCP-STD/
  13. Sean Turner: Discuss [2012-06-05]:
    
    This draft says:
    
    
    
      DCCP-UDP provides all of the security risk-mitigation measures
    
      present in DCCP-STD, and also all of the security risks.
    
    
    
    But the draft doesn't say anything about an MTI security mechanism.  If this is
    
    really based at NAT traversal, then you might want to say something about DTLS
    
    because DCCP points to IPsec, which is all kinds of fun to setup to traverse
    
    NATS.   Or is there some other mechanism that should be the MTI?
    
    
    
    If DTLS is invoked, then how does all that affect firewalls that intercept the
    
    messages?
    
    

draft-ietf-dane-protocol

  1. Russ Housley: Discuss [2012-06-06]:
    
    
    
      Please add a description of Full Certificate to Section 2.1.2.  I
    
      suggest: "Using the Certificate binary structure defined in [RFC5280]."
    
    
    
      Based on the briefing in the SAAG Session at IETF 83, I strongly
    
      suggest that this text be removed from Section 6.
    
      >
    
      > At the time this is written, it is expected that there will be a new
    
      > family of hash algorithms called SHA-3 within the next few years.  It
    
      > is expected that some of the SHA-3 algorithms will be mandatory
    
      > and/or recommended for TLSA records after the algorithms are fully
    
      > defined.  At that time, this specification will be updated.
    
    
  2. Russ Housley: Comment [2012-06-06]:
    
      Section 1.3 says:
    
      >
    
      > This document only applies to PKIX [RFC5280] certificates, not
    
      > certificates of other formats.  Later updates to this document might
    
      > specify how to use certificates in other formats.
    
      >
    
      I suggest that the second sentence be deleted.  Neither the TLS charter
    
      nor the DANE charter calls for support of new certificate formats.
    
    
    
      An informative reference to define "SSL proxy" would be very helpful.
  3. Barry Leiba: Comment [2012-06-06]:
    Substantive comments; these are non-blocking, but please consider them
    
    seriously, and feel free to chat with me about them:
    
    
    
    -- 1.2, last paragraph --
    
       This document only
    
       relates to securely associating certificates for TLS and DTLS with
    
       host names; other security protocols are handled in other documents.
    
    
    
    This makes it sound like there are other documents related to DANE for things
    
    like IPsec and SSH.  They're about keys in DNS in general, and the next sentence
    
    refers to non-DANE stuff.  Then the last sentence comes back to TLS/DTLS.
    
    
    
    I suggest doing this paragraph as two paragraphs, this way:
    
    
    
       Sentence 1.  Sentence 2.  Sentence 5.
    
    
    
       Sentence 3.  Sentence 4.
    
    
    
    And then re-phrase the new second paragraph to say something like,
    
    "...retrieving certificates from DNS for other protocols is handled in other
    
    documents."
    
    
    
    -- 1.3 --
    
       The DNSSEC signature needs to be validated on all responses
    
       that use DNSSEC in order to assure the proof of origin of the data.
    
    
    
    Don't *all* responses need to use DNSSEC, as well?  Or is it possible to have a
    
    mixture of DNSSEC and unsecured DNS responses?  Maybe it would be better to say
    
    it this way?:
    
    
    
    NEW
    
       The DNSSEC signature needs to be validated on all DNS responses
    
       in order to assure the proof of origin of the data.
    
    
    
    -- 2.2 --
    
       [in three places] MUST be represented as an 8-bit
    
       unsigned decimal integer.
    
    
    
    What does "decimal integer" mean?  I presume you should just take the word
    
    "decimal" out in all three places.  Or is there something I'm missing?
    
    
    
    -- 2.3 --
    
    The order here is odd: you haven't introduced the _443 and _tcp things
    
    yet, but you're showing them in the examples.  Maybe that's OK, but it feels a
    
    little confusing to me.  Consider moving the examples after Section 3 (to a new
    
    Section 4).
    
    
    
    -- 4.1 --
    
          If the DNSSEC validation state on the response to the request for
    
          the TLSA RRset is bogus, this MUST cause TLS not to be started
    
    
    
    Clearly, "bogus" is a technical term that means something distinct from
    
    "indeterminate or insecure" (in the next bullet).  Alas, I cut class the day
    
    they explained "bogus", and so I need an explanation.  Can you help?  (I can't
    
    explain why I didn't think about this when I reviewed -14; sorry.)
    
    
    
       Thus, in order to achieve
    
       any security benefit from certificate usage 0 or 1, an application
    
       that sends a request for TLSA records needs to get either a valid
    
       signed response containing TLSA records or verification that the
    
       domain is insecure or indeterminate.
    
    
    
    There you define two criteria:
    
    1. Get a valid signed response containing TLSA records.
    
    2. Get verification that the domain is insecure or indeterminate.
    
    
    
       If a request for a TLSA record
    
       does not meet one of those two criteria but the application continues
    
       with the TLS handshake anyway, the application has gotten no benefit
    
       from TLSA and should not make any internal or external indication
    
       that TLSA was applied.
    
    
    
    What indication might it make?  Are we just talking about audit logs of some
    
    sort?  In a user application, who will know or care about any indication that
    
    TLSA was applied?
    
    
    
    In any case, this sentence seems to say that the application can get neither of
    
     (1) or (2), and yet still continue with the TLS handshake.  It's advised not to
    
    set an indication that it's using TLSA, but that's not a MUST, and anyway it can
    
    go ahead with the handshake in any case.
    
    
    
       If an application has a configuration setting
    
       for turning on TLSA use, or has any indication that TLSA is in use
    
       (regardless of whether or not this is configurable), that application
    
       MUST not start a TLS connection or abort a TLS handshake if either of
    
       the two criteria above are not met.
    
    
    
    That sentence confuses me, for a couple of reasons.  It seems contradictory to
    
    the prior sentence.  If you didn't get what you expect...
    
    
    
    a. It says that if you have a configuration setting for TLSA, whether or not the
    
    setting is enabled, you have to abort.  I don't think that's what you mean.
    
    
    
    b. It says that if you ignored the advice above and set your indication anyway,
    
    you MUST NOT [if you keep this, you need caps on the "not"] do stuff.  But the
    
    previous sentence said you could go ahead anyway.
    
    
    
    c. The scope of the MUST NOT is wrong: it appears to say that you MUST NOT abort
    
    the TLS handshake, and I'm sure you don't mean that.
    
    
    
    d. If *either* of the two are not met?  You mean if *both* are not met, because
    
    getting either is OK (and they're mutually exclusive).  Right?
    
    
    
    -- 8.3 --
    
       For this reason, it is RECOMMENDED that DNSSEC validation always be
    
       performed on-host, even when a secure path to an external validator
    
       is available.
    
    
    
    I found this odd, because at several earlier points you talked about using an
    
    external validator with a secure path, and this is the first mention that it's
    
    not advisable.  Please consider a reference to this section the first time you
    
    talk about that option (Sec 1.3), possibly in 4.1 after the bullet list, and
    
    also in Appendix A.3.
    
    
    
    ========
    
    Other comments; no need to respond to these. Take them or modify them
    
    as you please:
    
    
    
    -- 2.1.2 --
    
       (Note that the use of "selector" in this document is completely
    
       unrelated to the use of "selector" in DKIM [RFC6376].)
    
    
    
    Was there really confusion about that?  Wow.  DKIM also doesn't have anything to
    
    do with certificates.  Oh, well... no harm in mentioning this.
    
    
    
    -- 8 --
    
       This in
    
       essence allows an intermediate CA to be come a trust anchor
    
    
    
    Typo: "become" should be one word.
    
    
    
    Last paragraph:
    
       While such trust is limited to the
    
       specific domain name, protocol, and port for which the TLSA query was
    
       made, local policy may deny to trust the certificate (such as due to
    
       weak cryptography), the same as it is with PKIX trust anchors.
    
    
    
    This is a really awkward sentence.  May I suggest this?:
    
    NEW
    
       While such trust is limited to the
    
       specific domain name, protocol, and port for which the TLSA query was
    
       made, local policy may decline to accept the certificate (for reasons such
    
       as weak cryptography), as is also the case with PKIX trust anchors.
  4. Pete Resnick: Comment [2012-06-06]:
    In general, I find section 3 wrongheaded. I think it was a poor design choice to
    
    use _port._protocol.rest.of.name. But a poor design choice is not a reason for a
    
    DISCUSS. However, I do think that the document should make *some* attempt to
    
    justify this poor design choice. Perhaps it's not a poor design choice at all
    
    and I'm all wet. But I'd like to hear an explanation. Section 1 says (emphasis
    
    mine, excerpted):
    
    
    
       TLS uses certificates to bind keys and *names*.
    
    
    
       The public CA model upon which TLS has depended is fundamentally
    
       vulnerable because it allows any of these CAs to issue a certificate
    
       for any *domain name*.
    
    
    
       The DNS Security Extensions (DNSSEC) provides a similar model that
    
       involves trusted keys signing the information for untrusted keys.
    
       However, DNSSEC provides three significant improvements.  Keys are
    
       tied to *names in the Domain Name System (DNS)*, rather than to
    
       arbitrary identifying strings; this is more convenient for Internet
    
       protocols.  Signed keys for any domain are accessible online through
    
       a straightforward query using the standard DNSSEC protocol, so there
    
       is no problem distributing the signed keys.  Most significantly, the
    
       keys associated with a *domain name* can only be signed by a key
    
       associated with the parent of that *domain name*; for example, the
    
       keys for "example.com" can only be signed by the keys for "com", and
    
       the keys for "com" can only be signed by the DNS root.  This prevents
    
       an untrustworthy signer from compromising anyone's keys except those
    
       in their *own subdomains*.
    
    
    
       DNS-Based Authentication of Named Entities (DANE) offers the option
    
       to use the DNSSEC infrastructure to store and sign keys and
    
       certificates that are used by TLS.  DANE is envisioned as a
    
       preferable basis for binding public keys to *DNS names*, because the
    
       entities that vouch for the binding of public key data to *DNS names*
    
       are the same entities responsible for managing the *DNS names* in
    
       question.
    
    
    
    Nowhere does it say that any legacy use of the CA model, nor any designed use of
    
    the DANE model, is about anything but a biding between keys and *domain names*.
    
    Yet section 3 goes on to add the additional design requirement that I use a port
    
    *and* a transport to identify the TLSA record I'm looking for. That prevents me
    
    from having a single TLSA record for "www.example.com", which I suspect will be
    
    the widest use case, unless I try to do crazy things with wildcards or DNAMEs
    
    (and all of their associated pain) as described in Appendix A. There was a
    
    requirement in 6394 that "DANE should be able to support multiple application
    
    services with different credentials on the same named host, distinguished by
    
    port number", but nowhere does that say that it has to be done on the lookup
    
    side. (For example, it could be that multiple TLSA records exist for
    
    "www.example.com", but they are distinguishable from the data returned. If data
    
    size was the problem, you could have had the TLSA records point to a record that
    
    actually contained the cert data.) And nowhere does 6394 say that multiple
    
    *transports* is a requirement. Note that 6394 also gives wildcard use as a
    
    requirement, but that is barely met by this document in that I can't wildcard
    
    "all names", but rather I must create subdomains of "_tcp.example.com" and
    
    "_udp.example.com" and "_sctp.example.com" and put wildcards under there. Even
    
    then, that does not allow me to wildcard all possible transports which I
    
    currently don't know about.
    
    
    
    So I think this was a terrible design choice. I don't think it reasonably
    
    satisfies the requirements of 6394. But a design choice it is. I do ask that you
    
    add some text justifying that design choice.

draft-ietf-codec-opus

  1. Stewart Bryant: Discuss [2012-06-07]:
    
    At this stage the authors do not need to do anything. I wish to discuss the
    
    following with my IETF collegues and will update this discuss accordingly.
    
    
    
    Given that the IETF knows of IPR claims and is publishing the software package
    
    as part of an RFC, I am concerned that we have an obligation to have included in
    
    the copyright notice a pointer to those IPR claims, lest at some point in the
    
    future the IETF are accused of failing to warn implementers of those claims.
    
    
    
    This may be something that needs clarifying with IETF council.
    
    
  2. Stewart Bryant: Comment [2012-06-07]:
    I am saddened that the IETF failed to meet the following goal for this work,
    
    i.e. to address the following:
    
    
    
    "There exist codecs that are standardized, but that cannot be widely
    
    implemented and easily distributed; according to reports, the presence
    
    of various usage restrictions (e.g., in the form of requirements to pay
    
    royalty fees, obtain a license, enter into a business agreement, or meet
    
    other special conditions imposed by a patent holder) has hindered
    
    adoptions of such codecs in interactive Internet applications."
  3. Ralph Droms: Comment [2012-06-06]:
    Is FEC really an accurate title for the mechanism described in section 2.1.7?
  4. Wesley Eddy: Comment [2012-06-06]:
    (non-blocking comments for the AD and editors)
    
    
    
    reference [Burg] has nothing but an author and title; it has to be locatable
    
    somehow other than google
    
    
    
    wikipedia references should be replaced by an actual textbook or other
    
    materials, in my opinion
  5. Adrian Farrel: Comment [2012-06-04]:
    I am balloting No Objection on this document on the basis that it has
    
    no impact on the internet's routing infrastructure, and that the WG and
    
    ADs have done a substantive review
    
    
    
    ---
    
    
    
    Per the Apps Dir review by Claudio Allocchio, I like the idea of adding
    
    a note (IESG Note?) to this document to highlight and make an exception
    
    of the use of code as a specification language.
  6. Stephen Farrell: Discuss [2012-06-06]:
    
    p20 says you MUST zero out padding bits. I wondered if
    
    there are any situations where so many zero'd padding bits would
    
    be sent and where the bits are being stream-enciphered that
    
    that'd create a problem. Dodgy stream-cipher setups have been
    
    seen in the wild in the past so this could in such a case be a
    
    real problem. One could say that these padding bits MUST be
    
    random or MUST be set to zero except when a stream cipher is
    
    used in which case they MUST be set randomly. While neither
    
    seems perfect, either would be better than exposing a key.  You
    
    can't tell from the ciphertext if there's a covert channel in
    
    any case, so zero'ing the padding bits is no help to any
    
    intermediary once they're sent with confidentiality. If this is
    
    a potential problem, it'd be good to know how often padding
    
    might happen and if there's any way to force it to happen by
    
    manipulating the channel. Perhaps the best thing to do here is
    
    change the MUST to a SHOULD and document the potential problem
    
    in the security considerations section.
    
    
  7. Stephen Farrell: Comment [2012-06-06]:
    
    - I agree that Pete's discuss needs to be resolved. It may be
    
    that there's a way to do that without the IETF trust owning the
    
    code, I don't know. I did also note that celt/pitch.c also has a
    
    CSIRO copyright from 2007-2008.  Were people from CSIRO involved
    
    in the WG? If so, does whatever code is involved constitute an
    
    IETF contribution (I would think so) and has someone checked
    
    that no IPR declarations from CSIRO are needed?  (Same question
    
    applies for all such contributors.) This is (I think) a varition
    
    on Pete's discuss since I guess that people from Xiph and Skype
    
    (the examples he quoted) have been involved in this work so any
    
    IPR declartions from them will have been done already.
    
    
    
    - If code comments conflict with the text of the body of the
    
    draft, then which is normative? Its clear that code wins but I'm
    
    not sure about comments within the code.  I'm ok with any
    
    reasonable answer here, but wanted to check.
    
    
    
    - The code contains things like "#ifdef FIXED_POINT" which is
    
    commented out in the top level Makefile. If the normative
    
    specification is the source code, what is the normative status
    
    of code that's only conditionally compiled and that is not
    
    compiled with the distributed Makefile? Have all such
    
    conditionally compiled code fragments been tested to the same
    
    extent as the code that is compiled with the default Makefile?
    
    I'm ok with any reasonable answer here, but wanted to check.
    
    
    
    - I think a few references to introductory materials about
    
    codecs would be useful in the intro for the poor victim^Wreader
    
    who's handed this and told to implement or optimise opus.
    
    
    
    - p13, [SRTP-VBR], RFC 6562, says that VBR SHOULD NOT be used
    
    for "highly sensitive" voice and goes on to say that VBR is ok
    
    if you're just matching the bandwidth but maybe not if the
    
    variation is driven by the speech signal. I think it'd be good
    
    to note both of those aspects here. I'd also personally prefer
    
    if both 6562 and this said "possibly sensitive" rather than
    
    "highly sensitive" since I don't know how code at this layer
    
    could know what's really sensitive or not. This might also be
    
    worth repeating in (or moving to) the security considerations as
    
    well as it would perhaps be more visible there.
    
    
    
    nits
    
    
    
    - p28, says "This same data MUST also be returned as raw bits
    
    when requested." Requested by whom? I didn't get that.
    
    
    
    - p30, says "this draft" s/draft/memo/ or whatever
    
    
    
    - p31, says "SHOULD take measures to conceal the error" but
    
    doesn't say what those might be 
    
    
    
    - p32, all those "1/8th bit" phrases read oddly to me but maybe
    
    that's standard fare for codec folks.
    
     
    
    - p151, says that padding is used in CBR mode but doesn't seem
    
    to say what kind of padding. If its the same as for my discuss
    
    (i.e. zero padding) then maybe the same considerations apply
    
    here? (Not sure)
  8. Brian Haberman: Comment [2012-06-06]:
    I support both Pete's and Sean's DISCUSS issues.
    
    
    
    I will also add that the instructions for extracting the source code does not
    
    work on a Mac running OS X 10.7.4.  The base64 utility present in OS X generates
    
    an unrecognizable archive format that cannot be decompressed by tar.
  9. Barry Leiba: Comment [2012-06-05]:
    Substantive comments; these are non-blocking, but please consider them
    
    seriously, and feel free to chat with me about them:
    
    
    
    -- 1.1.3 --
    
                        clamp(lo,x,hi) = max(lo,min(x,hi))
    
    
    
      With this definition, if lo > hi, the lower bound is the one that is
    
      enforced.
    
    
    
    I'm not sure I understand what that text means.  Are you saying that
    
    if, for example, you write "clamp(5,x,2)", it means the same as
    
    "clamp(2,x,5)" ?  If that's the case, then maybe it should be defined
    
    as this:
    
    
    
      clamp(a,x,b) = max(min(a,b),min(x,(max(a,b)))
    
    
    
    In any case, please re-phrase the text to make clearer what you mean.
    
    
    
    -- 4.4 --
    
    Have packet loss and clock drift been modelled, and have the
    
    recommendations in 4.4 and 4.4.1 thus been validated?  There seems to be a lot
    
    of speculation there, and I wonder how much basis in real experimentation there
    
    is.
    
    
    
    ========
    
    Other comments; no need to respond to these:
    
    
    
    This is easily the most technically dense and esoteric document I've every read,
    
    in the IETF or elsewhere.
    
    
    
    I'm not qualified to judge most of this document, and I expect that the number
    
    of people in the IETF who are can be counted on one hand.  I'm afraid that
    
    includes the participants in the codec working group, and that was one of the
    
    concerns some of us had when the WG was chartered.  How many in the working
    
    group *really* reviewed this entire document, and understand it?  How much
    
    consensus is there in the WG and in the IETF as a whole behind this, in all its
    
    details?
    
    
    
    That said, everything I can tell about this codec is that it's a good one, and
    
    that it was worth doing, despite the extraordinary number of IPR statements that
    
    apply to it (considering the WG's goals).  So I approve of the publication of
    
    it, and I've reviewed it as best I could.
    
    
    
    There was concern brought up in the Applications Directorate review about the
    
    mechanism of using C code as a specification.  I don't have a concern about
    
    that, and find it an acceptable mechanism.
    
    
    
    I did find myself wondering idly, as I read section 4.2.7.5.6, whether
    
    "cos(pi*n[k])" was intentional, and whether anyone asked Victoria's Secret about
    
    an IPR statement with respect to trademark....
  10. Pete Resnick: Discuss [2012-06-06]:
    
    Examining the source files and some of the other files, I find things similar to
    
    this:
    
    
    
       Copyright (c) 2011 Xiph.Org Foundation, Skype Limited
    
    
    
    I think the copyright for the source code should all be held by the IETF Trust
    
    with appropriate template information. The reason I am concerned that this might
    
    take a while is that in at least the case of the COPYING file in the root
    
    directory, the copyright is held by several organizations and individuals. I
    
    believe all of those folks must be contacted and explicitly agree to allowing
    
    their code to also be copyright by the IETF Trust.
    
    
    
    (The files in the git repository cited in the document probably also should have
    
    the IETF Trust copyright. Moreover, I would prefer to see the repository hosted
    
    on an IETF site rather than on github. I am concerned about drift of the code on
    
    github from the code in the RFC and ending up in a situation where the github
    
    version is -- de facto -- the place to go for the standard.)
    
    
  11. Pete Resnick: Comment [2012-06-06]:
    Like others, I don't feel I can give a substantive review to much of this
    
    document and will simply trust that it has gotten sufficient review. The one
    
    technical thing I noticed: A few variables that need to be unsigned because
    
    they're used in shift right (>>) operations are not explicitly specified as
    
    unsigned, in particular ft (used in 4.1.5) and b0 (used in 4.1.1). You do note
    
    other variables as unsigned, so I took these as omissions, but it may be clear
    
    from context. It seems to me a review of such variables might be useful.
    
    
    
    Like other ADs, I have some concerns about the use of source code for the
    
    normative spec:
    
    
    
    - First of all, this does turn the entire concept of "independent interoperable
    
    implementations" on its head. If the source code is normative, I don't see how
    
    we could ever judge that an implementation was independent and therefore how
    
    this spec would be advanced along the standards track.
    
    
    
    - Furthermore, I've got some concerns that we may, at some point in the future,
    
    encounter a small edge case where the code simply has a bug, but the text of the
    
    document makes it clear what the intention was. I would hate for us to say,
    
    "Well, the code is the normative reference, so the bug must stand and we must
    
    update the descriptive text to suit." I doubt that would happen, but we are in
    
    unchartered waters by using source as the normative spec.
    
    
    
    - Finally, the source code here is in base64, compressed, tarred format. It is
    
    completely unreadable in the spec. I do not know of any other RFC that has
    
    humanly-unreadable text in it. Again, we are in completely unchartered waters.
    
    
    
    And it is these "unchartered waters" that are the real issue all around. We may
    
    need to discuss how we handle this document now and in the future. But we signed
    
    up for this in the charter, so I'm willing to see it play out. There is no doubt
    
    that this document is an entirely odd duck.
  12. Martin Stiemerling: Comment [2012-06-05]:
    A nit:
    
    Section 3., paragraph 1:
    
    
    
    [...]
    
    >    the internal framing used to pack multiple frames into a single
    
    >    packet.  This framing is not self-delimiting.  Instead, it assumes
    
    >    that a higher layer (such as UDP or RTP [RFC3550] or Ogg [RFC3533] or
    
    >    Matroska [Matroska-website]) will communicate the length, in bytes,
    
    
    
      You mean that some lower layer (UDP, RTP, etc) will take care
    
     of this. Those are not higher layers in the IETF sense.
  13. Sean Turner: Discuss [2012-06-05]:
    
    Updated ...
    
    
    
    I haven't complete my review (this one is a beast), but I thought I'd start the
    
    process rolling:
    
    
    
    1) If we're going to be distributing source code:
    
    
    
    Can we include a sha1/sha256 checksums or something in the Appendix?  It's
    
    pretty common to do so when distributing source code.
    
    
    
    Could we also include the output of the idsigcheck code
    
    (https://tools.ietf.org/tools/idsigcheck/code) and place that somewhere
    
    permanent to make sure the contents haven't been doctored (and we're not
    
    distributing a virus).
    
    
    
    2) I glossed right over the pointer to the RFC in the previous paragraph.
    
    cleared this one...
    
    
    
    3) (right out of my league here and I'm sure there was some discussion about
    
    this)  There's also a file called copying - shouldn't it include the following:
    
    
    
    Copyright (c) <insert year> IETF Trust and the persons identified as authors of
    
    the code.  All rights reserved.
    
    
    
    and shouldn't it be in all the .h, .c, etc. files?
    
    
    
    4) (right out of my league here and I'm sure there was some discussion about
    
    this)  Some of the copyright years in the .h files are farther back the readme.
    
    opus_types goes back to 1994. Does the readme need to cover all the dates?
    
    
  14. Sean Turner: Comment [2012-06-05]:
    The following command in the appendix don't work:
    
    
    
    cat draft-ietf-codec-opus.txt | grep '^\ \ \ ###' | sed -e
    
          's/...###//' | base64 -d > opus_source.tar.gz
    
    
    
    I think you need to r/draft-ietf-codec-opus.txt/rfcXXXX.txt and note that the
    
    RFC editor should update this when it's published.

draft-ietf-mpls-ldp-gtsm

  1. Stephen Farrell: Comment [2012-06-05]:
    (1) 5082 has a MUST for authentication if negotiating GSTM.
    
    I don't get why this "built-in" negotiation, which seems to
    
    me to be added post-facto, gets around this need for strong
    
    authentication. I'm not going to insist that you define such
    
    authentication, (be nice if someone did though), but I do
    
    think you need to say you're not adhering to the MUST from
    
    5082.
    
    
    
    (2) When receiving an LDP Link Hello with G=1, what checks
    
    are to be made on the TTL for that packet? If you don't
    
    enforce GSTM on that, then presumably attacks could be
    
    mounted with a Link Hello that has G=0, defeating the
    
    negotiation (hence point (1) above I guess;-). Why is
    
    this ok? If you're really taking a "leap of faith" here,
    
    then that's probably fine, but should be stated IMO. In
    
    any case I think you need to be clear about whether the
    
    TTL on this packet needs checking or not.
    
    
    
    nits:
    
    
    
    - typo in section 3? "(i.e.,g G=1)" - s/g//?
    
    
    
    - typo in section 5: s/may cause LDP peering session/may
    
    cause an LDP peering session/
  2. Barry Leiba: Comment [2012-06-05]:
    Substantive comments; these are non-blocking, but please consider them
    
    seriously, and feel free to chat with me about them:
    
    
    
    -- 2.1 --
    
       The G flag is meaningful only if the T flag is set to 0 (which must
    
       be the case for Basic Discovery), otherwise, the value of G flag
    
       SHOULD be ignored on receipt.
    
    
    
    What happens if it isn't?  SHOULD means, basically, MUST unless you fully
    
    understand the consequences... so what are the consequences, so that an
    
    implementor might have a chance to understand them?
    
    
    
    ========
    
    Other comments; no need to respond to these. Take them or modify them
    
    as you please:
    
    
    
    -- 1 --
    
       Therefore, GTSM can fully benefit LDP protocol peering session
    
       established using Basic Discovery.
    
    
    
    I don't understand this sentence; maybe there's a word missing.  But it also
    
    seems awkward.  Does it mean this?:
    
    
    
    NEW
    
       Therefore, GTSM can provide full benefit to an LDP protocol
    
       peering session that was established using Basic Discovery.
    
    
    
       That is, the desire to use GTSM (i.e., its
    
       negotiation mechanics) is enabled by default without any
    
       configuration.
    
    
    
    But you just said that RFC 5082 said not to do that.  I understand what you're
    
    getting at, so maybe this will make it clear?:
    
    
    
    NEW
    
       That is, the desire to use GTSM (i.e., its
    
       negotiation mechanics) is enabled by default without any
    
       configuration, while retaining the spirit of the advice in
    
       RFC 5082.
  3. Sean Turner: Discuss [2012-06-05]:
    
    RFC 5082 says there's a MUST for authentication but doesn't say what mechanism -
    
    and that's fine.  LDP's authentication mechanism, TCP-MD5, must be a
    
    configurable option (i.e., not always used).  Doesn't using GSTM with LDP invoke
    
    a requirement to *use* the authentication mechanism (i.e., upgrade from a
    
    configurable option)?
    
    

draft-ietf-trill-rbridge-bfd

  1. Stewart Bryant: Discuss [2012-06-06]:
    
    This is I believe comparing the TRILL case with MPLS-TP
    
    
    
    "TRILL BFD uses the TRILL Rbridge Channel [TRILLChannel] similar to
    
    the way that MPLS OAM protocols use the MPLS Generic Associated
    
    Channel [RFC5586].  However, the RBridges that implement TRILL are
    
    IS-IS [IS-IS] based routers, not label switched routers; thus TRILL
    
    BFD is closer to IPv4/IPv6 BFD than to MPLS BFD."
    
    
    
    It is unclear what the above statement means. Whilst TRILL uses ISIS and MPLS-TP
    
    does not, the fundamentals high speed detection is is common to all. Where TRILL
    
    and MPLS-TP are closer than that are to the IP case is that neither have the use
    
    of IP addresses available to them.
    
    
  2. Stewart Bryant: Comment [2012-06-06]:
    I am surprised that TRILL did not take the opportunity to profile out the echo
    
    mode, since I understand that it is rarely used in IP networks and not used in
    
    MPLS_TP networks.
  3. Ralph Droms: Comment [2012-05-25]:
    From the shepherd writeup:
    
    
    
    There are references to section 10 and section 4, which
    
    should both be references to section 7.
  4. Adrian Farrel: Discuss [2012-06-06]:
    
    John Scudder raised a number of concerns in his Routing Directorate 
    
    review. I support these in my Discuss as follows.
    
    
    
    1. It is not clear why demand mode was explicitly excluded. TRILL
    
       would actually seem to be a reasonable fit for demand mode.
    
    
    
       Please either include demand mode, or a short note on why it is
    
       excluded.
    
    
    
    2. "there will be only a single TRILL BFD Control session between
    
       two RBridges over a given interface visible to TRILL."
    
    
    
       This text is a little hard to parse and may be ambiguous. Please
    
       find a way to re-write it with reference to a pair of RBridges RB1
    
       and RB2 and their interfaces RB1_Int1 and RB2_Int1. Or something
    
       like that.
    
    
    
    3. "the entire TRILL BFD Echo protocol specific
    
       data area is considered opaque and left to the discretion of the
    
       originating RBridge.  Nevertheless, it is RECOMMENDED that this data
    
       include information by which the originating RBridge can authenticate
    
       the returned BFD Echo frame and confirm the neighbor that echoed the
    
       frame back."
    
    
    
       The use of "RECOMMENDED" contradicts "left to the discretion of"
    
       because "RECOMMENDED" is a very strong encouragement to do something.
    
       I think you need "suggested" as this is just general advice to an
    
       implementation.
    
    
    
    4. In two places text like the following appears:
    
    
    
       "Is the M-bit in the TRILL Header non-zero?  If so, discard the 
    
       frame. TRILL support of multi-destination BFD Echo is beyond the
    
       scope of this document."
    
    
    
       If multi-destination doesn't make sense in the context of TRILL, it
    
       is fine to exclude it by enforcing that the M-bit be zero. However,
    
       "beyond the scope of this document" normally means something like 
    
       "we may do it in the future but haven't worked it out yet". By 
    
       forcing the discard under these conditions you are doing more than
    
       putting the function out of scope: you are disabling it.
    
    
    
       You might solve this by mandating the setting of the bit to zero,
    
       and saying that if the bit is non-zero the behavior is future
    
       description, and that an implementation MAY discard the packet.
    
       
    
    5. The Security Considerations section specifies how authentication is
    
       to be done, but doesn't provide an analysis of it or of any broader
    
       issues. According to RFC 3552 (Section 5) the Security Considerations
    
       section should include an analysis of issues that arise from the 
    
       operation of the protocol defined in the rest of the document,
    
       including but not limited to the security features of that protocol. 
    
    
    
       You could place the current text in a subsection of the Security 
    
       Considerations (called "Authentication") and add more text to the
    
       core section.
    
    
    
    Additionally, I think you are missing a normative reference to
    
    https://datatracker.ietf.org/doc/draft-ietf-trill-rbridge-oam/
    
    This is necessary to set the context for why you are using BFD and
    
    for what purpose. It would also clarify which BFD features are needed
    
    and what OAM features (from the whole set) are addressed by BFD.
    
    
    
    Finally, although I understand that the scope of this document is
    
    limited to encapsulation, I think that this leaves the solution
    
    deficient. It needs a description of bootstrapping in the Trill
    
    environment.
    
    
  5. Adrian Farrel: Comment [2012-06-06]:
    It is very odd to bring this document forward ahead of the normatively
    
    referenced draft-ietf-trill-rbridge-channel  
    
    
    
    Doing this makes the review less certain.
  6. Stephen Farrell: Comment [2012-06-05]:
    
    - I'm not clear if the key derivations described in section
    
    6 are mandatory to implement or not. It says that if IS-IS
    
    auth is in effect, then you "use" (would that be better with
    
    a 2119 MUST?) BDF Meticulous Keyed SHA1 (nice name btw:-),
    
    but its not clear to me if that means this is MTI or not.
    
    
    
    - What does "that state of IS-IS shared secret" mean?  Maybe
    
    s/that state//?
    
    
    
    - I don't get why this only needs/uses key ID 0, can you
    
    explain further? I guess I'd have expected that if the
    
    IS-IS-shared-key had a key ID, then that would be used for
    
    the derived key(s) defined here.
    
    
    
    - I'm wondering if the authentication scheme described here
    
    is really used or not? I think it'd be good to say if its
    
    real or fictional, if that is known.
  7. Brian Haberman: Comment [2012-06-04]:
    Thank you for addressing my DISCUSS so quickly.
  8. Barry Leiba: Comment [2012-06-05]:
    Minor comments; no need to respond:
    
    I find citing nroff in the Acknowledgments
    
    section to be odd, for whatever that's worth.  (I also can't remember when I
    
    last saw an actual normative reference to ASCII.)
  9. Robert Sparks: Comment [2012-06-06]:
    I agree with the shepherd's recommendation to change the reference for [ASCII]
    
    to ANSI X3.4. I suggest looking at the references in RFC5891 for an example:
    
    
    
    [ASCII]      American National Standards Institute (formerly United
    
                    States of America Standards Institute), "USA Code for
    
                    Information Interchange", ANSI X3.4-1968, 1968.  ANSI
    
                    X3.4-1968 has been replaced by newer versions with
    
                    slight modifications, but the 1968 version remains
    
                    definitive for the Internet.
  10. Martin Stiemerling: Discuss [2012-06-04]:
    
    I wonder if what is said about congestion control  in Section 7 of RFC 5880 is
    
    also applicable to this draft.
    
    
    
    The current draft text denies this, as it states in Section 5:
    
    >    It is up to the operator of an RBridge campus to configure the rates
    
    >    at which TRILL BFD frames are transmitted on a link to avoid
    
    >    congestion (e.g., link, I/O, CPU) and false failure detection.
    
    
    
    This seems to be absolutely contradicting RFC 5880 on the matter of congestion
    
    control.
    
    
  11. Sean Turner: Discuss [2012-06-06]:
    
    s6 contains the following:
    
    
    
       If such IS-IS authentication is in effect then, unless configured
    
       otherwise, TRILL BFD Control frames sent between those RBridges use
    
       BFD Meticulous Keyed SHA1 authentication [RFC5880] with keying
    
       material derived as shown below
    
    
    
    I think you need to say what the MTI is in this case.  That might be as simple
    
    as adding "MUST" before "use" but that's a little more than MTI that's mandatory
    
    to use.  Are you trying to say that in this case,  BFD Meticulous Keyed SHA1
    
    authentication [RFC5880] with keying material derived as shown below MUST be
    
    supported as a configurable option: ey [material derivation here]?
    
    

draft-ietf-dnsext-dnssec-bis-updates

  1. Stephen Farrell: Comment [2012-06-05]:
    
    During the "no answer" mega-discussion on the DANE list, [1] I
    
    seem to recall this comment was made more than once: "you're
    
    seeing all this because you're maybe the first new
    
    application that really needs DNSSEC," or words to that
    
    effect. Should any of that discussion be reflected in this
    
    document? (I assume its not already there for timing reasons
    
    if nothing else.)
    
    
    
       [1] http://www.ietf.org/mail-archive/web/dane/current/msg04845.html
  2. Russ Housley: Discuss [2012-06-01]:
    
    
    
      The Gen-ART Review by Richard Barnes on 25-May-2012 raised two major
    
      concerns.  The Gen-ART Review can be found here:
    
      http://www.ietf.org/mail-archive/web/gen-art/current/msg07454.html
    
    
    
      Building on this review, I have these suggestions:
    
    
    
      (1) Section 4.1:  Please clarify the threat model.  If the zone
    
      operator is malicious, then it can simulate the necessary zone cut
    
      and still prove the non-existence of records in the child zone.
    
    
    
      (2) Section 5.10:  Please explain why the "Accept Any Success" policy
    
      is more preferable the "Highest Signer" policy.  This analysis might
    
      not appear in Section 5.10; it could appear in an appendix.
    
    
  3. Barry Leiba: Comment [2012-06-05]:
    Substantive comments; these are non-blocking, but please consider them
    
    seriously, and feel free to chat with me about them:
    
    
    
    Ditto Sean's comments about DNSSEC vs DNSSECbis, and about Draft Standard ->
    
    Internet Standard.
    
    
    
    -- 2.1 --
    
       signal that a zone MAY be using NSEC3, rather than NSEC.
    
    
    
    This MAY and the one in the following paragraph are misused: they should not be
    
    2119 terms.  Describing what a zone "may be using" is simply a descriptive
    
    phrase, not anything normative.  Actually, I would say "might be using".
    
    
    
    -- 5.2 --
    
    Isn't the point really more general: that if the validator is unable
    
    to validate the signature, *for whatever reason*, it treats the zone as
    
    unsigned?  Wouldn't it be better to make that general point clear... and then
    
    give unknown or unsupported key or message digest algorithms as reasons it would
    
    be unable to validate?
    
    
    
    ========
    
    Other comments; no need to respond to these. Take them or modify them
    
    as you please:
    
    
    
    -- 2 --
    
    There's a SSnake in the graSSS in the SSection title.
  4. Robert Sparks: Comment [2012-06-05]:
    Is there a reference that could be added to section 3.1 to where the scaling
    
    concerns called out there are discussed?
  5. Sean Turner: Comment [2012-05-25]:
    These are my preliminary sets of comments:
    
    
    
    1) Any reason you can't just refer to DNSSECbis as DNSSEC?  I guess does the
    
    outside world know DNSSECbis isn't DNSSEC?
    
    
    
    2) General: r/RFCXXXX/[RFCXXXX] throughout except for the abstract.  A couple of
    
    times I thought the RFC references needed to be included in [] so it's probably
    
    better to just do it everywhere.  You also need to add [RFC2308] as a reference.
    
    
    
    3) s1 paragraph two: RFC 6410 got rid of Draft Standard so either
    
    r/Draft/Internet or r/from Proposed Standard to Draft Standard/along the
    
    Internet Standards track.    Or something like that.
    
    
    
    4) s1.2: To cut down on the possible "where is X defined" you could add
    
    something like: "Readers are assumed to be familiar with DNSSECbis documents as
    
    the terminology used herein comes from those documents."
    
    
    
    5) s2, s2.1, s2.2: Could you replace the three instances of "should {also} be"
    
    with "are"?  If the WG considers them part of the core, then aren't they?  It
    
    also avoids the whole question about whether it ought to be SHOULD (not that I'm
    
    asking to change that).
    
    
    
    6) s2.1: Pet peeve requirements in a paragraph that starts with Note.  Couldn't
    
    you just r/Note that the/The
    
    
    
    7) s5.5: Might be worth pointing out that this was filed as an errata.
    
    
    
    8) s5.6, s5.7, and s5.10: I was already to give you the kudos for each section
    
    being clear about which document was being updated until I got to these
    
    sections.  Please state which RFC you're updating in these sections.  In s5.6 is
    
    it updating 3225?
    
    
    
    9) s5.11: could you just strike "note that"

draft-ietf-trill-rbridge-extension

  1. Ronald Bonica: Discuss [2012-06-06]:
    
    Could you provide use-cases for this extension mechanism? What extensions do you
    
    intend to define? How do these extensions fit into your current charter?
    
    
  2. Wesley Eddy: Comment [2012-06-04]:
    I had questions that overlapped a subset of Adrian's COMMENT, so would encourage
    
    the authors and AD to pay attention to his ballot.
  3. Adrian Farrel: Comment [2012-06-04]:
    I have no objection to the publication of this document.
    
    
    
    I have a number of questions and issues you might want to look at before
    
    the document is published as an RFC.
    
    
    
    ---
    
    
    
    Does this document update 6325?
    
    
    
    ---
    
    
    
    Abstract say...
    
    
    
       This document specifies an initial extension providing
    
       additional flag bits and specifies two of those bits.
    
    
    
    The Introduction says...
    
    
    
       This
    
       document specifies an initial extension providing additional flag
    
       bits and specifies one of those bits.
    
    
    
    Anyway, it appears you define the meaning of three bits (if you include
    
    CRSVS). And, through the definition of the structure, you sort of define
    
    the meaning of the others.
    
    
    
    ---
    
    
    
    If there is an indication that at least one CHbH option present, does
    
    each hop have to scan all options to check whether they are relevant?
    
    This seems to be a compounding factor for the note in Section 2.
    
    
    
    The note is good, but I wonder what the consequences is of an increased
    
    likelihood of dropping a packet with a hop-by-hop critical option.
    
    
    
    ---
    
    
    
    In section 2
    
    
    
          o  flag affecting an as yet unspecified class of RBridges, for
    
             example border RBridges in a TRILL campus extended to support
    
             multi-level IS-IS
    
    
    
    It seems odd that if the class of RBridges is unspecified, you can give
    
    an example like this. I suggest that you rebrand this flag as reserved
    
    for future extensions, or go to the trouble of defining its real use.
    
    
    
    The same ambiguity arises in the text describing CRSVS in 2.3.1
    
    
    
    BTW s/flag/flags/ ?
    
    
    
    ---
    
    
    
    Section 2
    
    
    
       if it is a
    
       known unicast frame
    
    
    
    Are there unicast frames where it is impossible to know that they are
    
    unicast?
    
    
    
    ---
    
    
    
    Section 2.3
    
    
    
       (The first two critical summary bits are as specified in [RFC6325].
    
       In this document an "S", for Summary, has been added at the end of
    
       their acronyms.)
    
    
    
       Bit(s)   Description
    
       ---------------------
    
    
    
        0-3  Crit.: Critical summary bits.
    
             0 CHbHS: Critical Hop-by-Hop extension(s) are present.
    
             1 CItES: Critical Ingress-to-Egress extension(s) are present.
    
             2 CRSVS: Critical reserved extension(s) are present.
    
    
    
    The bracketed text is a little confusing. There are indeed only two
    
    summary bits defined in 6325. There is a third bit defined here. All
    
    three bits have been given an "S" suffix.
    
    
    
    ---
    
    
    
    Is section 2.4 simply egg sucking, or is there something else that needs
    
    to be explained?
  4. Stephen Farrell: Discuss [2012-06-05]:
    
    I don't understand the security model for the
    
    ingress-to-egress extensions. Given that hop-by-hop
    
    extensions can be modified/dropped, there can be no
    
    ingress-to-egress cryptographic security, however this is not
    
    stated. Were it stated, it would appear to make all
    
    extensions hop-by-hop, at least in terms of (non)end-to-end
    
    security. Either that or you need a quite complex set of
    
    security mechanisms, which I assume you don't want.  Or,
    
    perhaps the WG were happy that introducing extensions like
    
    this, means never being able to use cryptographic security
    
    and extensions between ingress and egress? (Or some highly
    
    complex in-between state.) I'm not looking for any specific
    
    change for now, but rather just to understand what's the
    
    expectation here for e2e-like cryptographic security.
    
    
  5. Stephen Farrell: Comment [2012-06-05]:
    
    - Pure opinion from a TRILL-ignoramus: this seems over
    
    complex to me.
    
    
    
    - I don't get how the TLVs are encoded, and associated with
    
    the various flag fields, e.g. CItE etc. That may be "obvious"
    
    but I didn't get it at all sorry. 
    
    
    
    - I don't get how extended flag thing is supposed to work.
    
    How is someone supposed to know when to allow addition of the
    
    bicycle extension?
    
    
    
    - This: "Any extended flag indicating a significant change in
    
    the structure or interpretation of later parts of the frame
    
    which, if the extended flag were ignored, could cause a
    
    failure of service or violation of security policy MUST be a
    
    critical extension. If such an extended flag affects any
    
    fields that transit RBridges will examine, it MUST be a
    
    hop-by-hop critical extended flag" seems like it'd be a fine
    
    source for useless rathole arguments.
    
    
    
    - What does: "A transit or egress RBridge may assume that the
    
    critical summary bits are correct." mean?
    
    
    
    - This seems very odd: "Conflicting extensions SHOULD NOT be
    
    defined, but if they are,..."
  6. Barry Leiba: Discuss [2012-06-05]:
    
    -- 5 --
    
    Please explain (briefly -- a sentence or two will surely do) the reason
    
    for selecting Standards Action for this registry.  I'd prefer it if that
    
    sentence or two were in the IANA Considerations, unless there's a reason not to
    
    put it there.
    
    
    
    I understand that there is a limited number of bits to be given out, so freely
    
    allocating them for the asking would be harmful.  Still, Standards Action is
    
    very heavyweight: did you consider IETF Review (which could allow Informational
    
    or Experimental documents to do allocations, with community consensus and IESG
    
    approval), or even Specification Required (where you could give instructions
    
    that the designated expert exert tight control over the allocations)?
    
    
  7. Barry Leiba: Comment [2012-06-05]:
    What Adrian said....

draft-ietf-mile-iodef-xmlreg

  1. Benoit Claise: Comment [2012-06-05]:
    Section 1, Introduction
    
    IODEF extensions via class extension through AdditionalData and
    
       RecordItem elements, as per section 5.2 of [RFC5070], generally
    
       register their namespaces and schemas with the IANA XML Namespace
    
       registry at ...
    
    
    
    => remove "generally"
    
    
    
    - There is one nit catched by the nit checker:
    
    
    
    => The draft header indicates that this document updates RFC5070, but
    
    the abstract doesn't seem to mention this, which it should.
  2. Russ Housley: Comment [2012-06-05]:
    
      Please consider the editorial comments in the Gen-ART Review by
    
      Suresh Krishnan on 5-Jun-2012.  The review can be found here:
    
      http://www.ietf.org/mail-archive/web/gen-art/current/msg07483.html
  3. Pete Resnick: Discuss [2012-06-05]:
    
    This document defines no protocol, does not say how to implement a protocol, and
    
    does not have anything to do with a protocol except for information about how an
    
    IANA registry is to be used. Why is this going on the standards track? This
    
    should either be Informational, or more likely BCP.
    
    
  4. Robert Sparks: Comment [2012-06-05]:
    Consider "designated by the IESG" instead of "designated by the IETF Security
    
    Area Directors."

draft-ietf-manet-nhdp-mib

  1. Ronald Bonica: Comment [2012-06-04]:
    This document fails to provide use cases. Because it doesn't provide use cases,
    
    it is not clear that any/all of its objects are useful.
    
    
    
    While this comment might be leveled concerning regarding MIB, it is particularly
    
    applicable in this case because we have so little operational experience with ad
    
    hoc networks. Will the ad hoc network include a NOC? What policy will that NOC
    
    attempt to enforce? What information/control will the NOC need to enforce that
    
    policy.
  2. Stewart Bryant: Comment [2012-05-23]:
    I am voting no objection on the basis that other members of the IESG who are
    
    more knowledgeable on MIBS will have reviewed this.
  3. Benoit Claise: Discuss [2012-06-06]:
    
    - There is a clear DISCUSS coming from the MIB-doctor review. Please address it.
    
    
    
    - While reading through the document, I've been really waiting for an
    
    applicability statement section.
    
    A sentence [RFC6130] such as "if router A is
    
    able to exchange packets with router B, and router B is able to exchange packets
    
    with router C, this does not guarantee that router A and router C can exchange
    
    packets directly" got me thinking about the management and operational aspects.
    
    How do you plan on using this MIB module, taking into account that you're
    
    dealing with an ad-hoc network?
    
    
    
    Note that the write-up mentions: "This document shepherd is not aware of
    
    existing implementations of this MIB although several implementers have
    
    indicated interest in the work."
    
    So the potential implementers should have some
    
    views on the following questions.
    
    
    
    I'm really after 3 different parts in the applicability statement (or call it
    
    use cases if you want to): configuration management, monitoring, and
    
    notification. And I have questions such as:
    
    * one static NMS or each MANET
    
    router configures/monitors his (newly attached) neighbor(s)?
    
    * where are the
    
    notifications sent to?
    
    * Do you expect all MANET routers to always have
    
    connectivity to a static NMS?
    
    * etc...
    
    Obviously, monitoring, for example, is
    
    important in ad-hoc networks, but please let us know how you envision doing
    
    this. For example, right now, I see the term "appropriate SNMP management
    
    stations", and I have no clue what's "appropriate" in the management of an ad-
    
    hoc network.
    
    
    
    I see some other MANET MIB modules...
    
    * draft-ietf-manet-olsrv2-mib-04
    
    Definition of Managed Objects for the Optimized Link State Routing Protocol
    
    * draft-ietf-manet-report-mib-02        Definition of Managed Objects for
    
    Performance Reporting
    
    * draft-ietf-manet-smf-mib-04   Definition of Managed
    
    Objects for the Manet Simplified Multicast Framework Relay Set 
    
    However, this
    
    document is the first MANET MIB module to reach the IESG, so those operational
    
    questions are important.
    
    If this is expressed in a different document, let me
    
    know, and I can review it.
    
    
    
    Along the same lines, 
    
    1. see Al Morton's review, part of the OPS-DIR
    
    > General question: Is a lossy, mobile ad-hoc network compatible with
    
    > SNMPv3? In other words, will the link performance information needed
    
    > for troubleshooting really be available when it is needed most, and
    
    > critical nodes may be unreachable?
    
    2. Read Ron's Bonica's Abstain
    
    
  4. Benoit Claise: Comment [2012-06-06]:
    - Abstract
    
    
    
       This document defines a portion of the Management Information Base
    
       (MIB) for use with network management protocols in the Internet
    
       community.  In particular, it describes objects for configuring
    
       parameters of the Neighborhood Discovery Protocol (NHDP) process on a
    
       router.  
    
    
    
    Should this be "MANET router"?
    
    "MANET router" is used in RFC6130
    
    Alternatively, I see in this document:
    
    	"NHDP router"
    
    	"router in a Mobile Ad Hoc Network (MANET)"
    
    Same remark for the introduction, which uses the same text.
    
    
    
    - First occurence of NHDP must be expanded.
  5. Stephen Farrell: Comment [2012-05-21]:
    I agree with Sean's discuss. DES just isn't up to this these
    
    days.
    
    
    
    p60 - I think you mean confidentiality and not privacy?

draft-melnikov-smtp-priority

  1. Stewart Bryant: Comment [2012-06-07]:
    I agree with Adrian's comments
  2. Wesley Eddy: Discuss [2012-06-05]:
    
    The document talks about end-to-end use across a mix of MTAs that do or do-not
    
    support the extensions, but not across MTAs with different administrators.  The
    
    applicability of this mechanism would seem to apply only to a single "domain" of
    
    administration, where control of incoming messages at the edge can be performed
    
    to make sure the system isn't abused.  I think the same problems from
    
    interdomain IP QoS apply here as the initial MTA where the priority was approved
    
    may not be able to tell if it will be approved all the way across the path of
    
    other MTAs to the destination.
    
    
    
    In the case where there are multiple MX records, I believe this document is
    
    only advocating continuing to use the record that was selected based on the RFC
    
    5321 algorithm (using the specified record priority, or randomly within a single
    
    priority) and doesn't attempt to "balance load" across them.  The assumption
    
    here must be that the network resource bottleneck is shared between this MTA and
    
    the multiple potential next-hops.  If there's a situation where there isn't a
    
    shared bottleneck, however, this assumption will not lead to optimal behavior,
    
    and I think the topic should at least be touched upon and discussed somewhat.
    
    
  3. Wesley Eddy: Comment [2012-06-05]:
    I agree with Martin's DISCUSS point that in Section 5.1, "congestion" refers to
    
    existence of a queue at the application layer, and does not have anything to do
    
    with network-layer congestion which should probably be clarified.
  4. Adrian Farrel: Comment [2012-06-04]:
    I have no objection to the publication of this document.
    
    
    
    ---
    
    
    
    Are you sure you have not conflated priority and importance?
    
    High priority messages need to be delivered quickly and an
    
    implementation may want to let them overtake lower priority messages.
    
    High importance messages need to be delivered (eventually) and should
    
    have a lower chace of being dropped.
    
    
    
    4.1 with its ability to reject low priority messages appears to be
    
    doing importance.
    
    
    
    ---
    
    
    
    Appendix E gives some motivations for 19 priorities. It seems like a
    
    very large number to me. Experience with this sort of range of options
    
    and priority levels suggests that it only adds confusion. I suppose my
    
    question is: are you sure?
  5. Stephen Farrell: Comment [2012-06-05]:
    
    - (An almost "discuss"): 4.6 means that anyone who is ok to
    
    send me a prio=9 message can cause me to send a whole bunch of
    
    prio=9 messages (as DSNs). Is that not a new DoS vector? 
    
    Please explain why not.
    
    
    
    (The rest are not near-discusses btw.)
    
    
    
    - The writeup is somewhat coy about the use-case. Its military
    
    messaging, ala STANAG 4406/ACP 123.
    
    
    
    - I don't get why the EHLO keyword has no parameters.  I'd
    
    have thought that a parameter there could be a useful way to
    
    signal some semantics for MT-PRIORITY values. Maybe that was
    
    discussed before though. (I've not kept up with all the mail
    
    on this draft btw.)
    
    
    
    - I agree that the "untrusted source" concept in 4.1 seems
    
    broken and that a resolution such as that discussed via email
    
    seems right, that is, that this is down to bilateral agreement
    
    really rather than being tied to SMTP AUTH so directly.
    
    
    
    - Is 4.3 really needed? Seems like its not about relaying but
    
    is generally true.
    
    
    
    - What exactly does "retain" mean in 4.4? I guess it means
    
    that the MLA MUST forward the mail with the same MT-PRIORITY
    
    value to any next-hop that supports it. But what if only 50%
    
    of the next-hops for a given message support this?
    
    
    
    - I don't get what X.3.TBD2 means at the end of p7.  (I even
    
    looked at 2034 and still don't get it.)
    
    
    
    - Saying its "important" for MUAs to support this spec seems
    
    over-stated. If you want to keep the term "important" then I
    
    guess it'd be good to specify to whom what is important? (Not
    
    all players in this space have commensurate interests.)
    
    
    
    - 5.1, possible nit, possible significant comment. A lower
    
    priority message could be sent first with advantage to all.
    
    If e.g. the sending MTA knows that sending the higher priority
    
    message over a later, but "better", interface, e.g. that is
    
    currently down. This is a familiar concept when dealing with
    
    contacts in DTNs. I think maybe it'd be better to talk about
    
    trying to get the mail delievered earlier rather than the
    
    speciifics of how priorities map to sending things from
    
    queues.
  6. Brian Haberman: Comment [2012-06-04]:
    I agree with Adrian's comment that 19 priorities may be hard to manage.
  7. Robert Sparks: Discuss [2012-06-06]:
    
    1) There is some tension between the requirements in Sections 4.1 and 4.2
    
    (highlighted by a requirement in Section 10).
    
    
    
    Section 4.1 says "The SMTP server MAY also alter the message priority (to lower
    
    or to raise it) in order to enforce some other site policy."
    
    
    
    Section 10 reinforces that MTAs "MAY override the priority values"
    
    
    
    But Section 4.2 to take the results of 4.1 (which includes the possibility of
    
    changing the message priority), but goes on to say:
    
    
    
    "For example, once an MTA accepts a message, the MTA MUST NOT change a
    
    (syntactically valid) priority value if that value is not supported (as a
    
    distinct priority value) by the MTA's implementation of this extension."
    
    
    
    This appears to be a conflict. Would it better capture the intent to change that
    
    last sentence to sat "only because that value is not supported" instead of "if
    
    that value is not supported"? If so, I suggest rewriting the sentence without
    
    using the 2119 MUST NOT. Would the following work? (Adam Roach put this
    
    together):
    
    
    
    "An MTA that supports the MT-PRIORITY extension MUST include an MT-PRIORITY
    
    parameter whenever it relays a message to an MTA or MDA that also supports the
    
    MT-PRIORITY extension. The MTA sets the value of the MT-PRIORITY parameter
    
    according to its local policy. In the absence of a policy-based reason for
    
    adjusting the value, the MTA SHOULD set the MT-PRIORITY parameter to the value
    
    determined from the procedure described in section 4.1. Note that this value
    
    might be different than the priority level at which the MTA actually handles the
    
    request, due to the rounding described in section 5."
    
    
    
    Section 5 also reiterates this MUST and might need to be adjusted to match.
    
    
    
    2) Amplifying Stephen's almost-discuss: Do we really want to preempt real
    
    messages in favor of DSNs? If so, are there security considerations specific to
    
    DSNs that this document should point to (that would discuss how to mitigate
    
    large numbers of malicious DSNs)?
    
    
    
    3) Section 5.4 restricts MTAs from rejecting messages based on priority or
    
    priority+size (arguing that only MSAs should do so). Why is this particular kind
    
    of rejection being treated differently than other kinds of rejections at MTAs?
    
    Is there a general requirement to avoid these bounces in another document you
    
    can point to instead? If not, a discussion of the tradeoffs of a policy that
    
    would result in a rejection seems more appropriate than a normative restriction
    
    to not reject.
    
    
    
    4) What discourages an MUA (the UA, not the user) that gets a rejection stating
    
    that its priority was too low from immediately resubmitting the request with a
    
    higher priority? Is there anything that discourages a user from doing so?
    
    
    
    5) (The clarification the Transport ADs have asked for may obviate this). Can
    
    the document clarify why and when an MTA would want to open a new connection for
    
    sending higher priority messages? If it has a connection already, why wouldn't
    
    it just use that? If there's no transport congestion, and the queues behind the
    
    existing connection are backing up, how is opening a new connection going to
    
    help? If there _is_ transport congestion, opening a new connection is going to
    
    hurt.
    
    
  8. Martin Stiemerling: Discuss [2012-06-05]:
    
    I have a DISCUSS about this paragraph and the benefit of this mechanism:
    
    
    
    Section 5.1., paragraph 6:
    
    
    
    >    This extension provides benefits in networks with limited available
    
    >    bandwidth or long round trip times, when the actual message transfer
    
    >    over the network can create a significant portion of the overall
    
    >    message delivery time from a sender to a recipient.  It is also
    
    >    useful in case of a congestion, for example resulting from an MTA
    
    >    queue build-up.  When neither of the two conditions mentioned above
    
    >    is true, the use of the MT-PRIORITY SMTP extension will not result in
    
    >    a better SMTP service.
    
    
    
    Congestion is there if the incoming rate is higher than the outgoing rate on a
    
    bottleneck. How does this mechanism help when there is congestion?
    
    This isn't
    
    clear to me at all.
    
    
    
    First of all, this seems to be talking about congestion on the SMTP level and
    
    not necessarily at the transport level. 
    
    Please clarify this in the text.
    
    
    
    This mechanism can even increase the queue length at a MTA, if high priority
    
    messages arrive at the same rate (or even higher) than the outgoing rate from
    
    that MTA. This situation would also occur without the priority mechanism, but
    
    the mechanism can make the situation even worse for lower priority messages. The
    
    will be queued up and potentially starve to death in the queue, if higher
    
    priorty messages keep arriving and they are being jumped to the front or
    
    near
    
    front of the queue.
    
    
    
    I do not see that it is safe to state that this mechanism will help in
    
    congestion at the SMTP level.
    
    
    
    Further, how is the queue to be managed with the different priority levels?
    
    
  9. Martin Stiemerling: Comment [2012-06-05]:
    - I agree with Adrian about the really high number of priority levels
    
    
    
    - What do the priority level mean in a multi-domain scenario, i.e., two domains
    
    can have a completely different understanding about what a particular level
    
    means.
    
    
    
    - Section 6., paragraph 0:
    
    
    
    >    Unextended SMTP does not offer a service for timely delivery.  The
    
    >    "Deliver By SMTP Service Extension" (DELIVERBY Extension) defined in
    
    >    [RFC2852] is an example of an SMTP extension providing a service that
    
    >    can be used to implement such constraints.  But note that use of the
    
    >    DELIVERBY extension alone does not guarantee any priority processing.
    
    
    
    Does this extension allow timely delivery?
    
    Or is it simply trying to enhance
    
    timely delivery?
    
    And what is timely delivery?
    
    I don't see how this is offering a
    
    service for timely delivery in all circumstances.
  10. Sean Turner: Discuss [2012-06-05]:
    
    Is it appropriate for the IETF to recommend the mappings for others (thinking
    
    here mostly about MMHS and NS/EP values) in App A and C?  Seems like we ought to
    
    define the mechanism and then somebody representing those communities defines
    
    what values they want?
    
    
  11. Sean Turner: Comment [2012-06-06]:
    Updated #4 based on some IMs with Alexey:
    
    
    
    0) BTW - my initial thought about this draft was "I wish I had of thought of
    
    this ten yeas ago."  Really hoped you'd go all the way and have different
    
    precedences/priorities for the to and cc recipients ;)
    
    
    
    1) App A: Actually ACP123/STANAG 4406 specifies a range from 0-31.  And (this
    
    relates to the discuss) if somebody specifies four more values higher than
    
    override how will the mapping get done?
    
    
    
    2) App A: In 123/4406, there's priority and precedence.  The values you list are
    
    from precedence so I assume you're talking about those values and not the
    
    urgent, routine, and non-urgent values for priority.  App A says priority
    
    though:
    
    
    
       Military Messaging as specified in ACP 123 [ACP123] (also specified
    
       in STANAG 4406 [STANAG-4406]) defines six priority values.
    
    
    
    3) App B contains the following:
    
    
    
       Where SMTP is used to support military messaging, the following
    
       mappings SHOULD be used.
    
    
    
    Should this say mixer instead of military messaging?
    
    
    
    4) I'm trying to wrap my head around why if you go from MMHS to SMTP you'd map
    
    urgent and flash to different level but if you went through MIXER to get to SMTP
    
    you'd get flash and override mapped to the same level (urgent)
    
    
    
    And, what do you do if both primary-precedence and mixer priority are there?

draft-ietf-appsawg-about-uri-scheme

  1. Adrian Farrel: Comment [2012-06-03]:
    I have no objection to the publication of this document as an
    
    Informaitonal RFC.
    
    
    
    Following on from the transition to Informational (for which, thanks),
    
    you might consider s/specifies/describes/  (But this is a *very*
    
    unimportant comment!)
  2. Stephen Farrell: Comment [2012-06-04]:
    
    The FCFS registration scheme could lead to anyone
    
    registering an about-token that's in current use in a 
    
    browser. Why isn't expert review more suitable here to
    
    protect against such abuse? For example, nothing 
    
    here prevents me from registering about:config, which
    
    is used by >1 browser. I don't get why that is not
    
    a problem. (This is almost a discuss btw, I'd really like 
    
    to see a response if possible before the telechat.)
    
    
    
    Why does about-token "correspond" to hier-part from 3986?
    
    What would "about://example.com/foo/bar" mean? I'd have
    
    thought that omitting the authority would be correct for
    
    this scheme - why am I wrong?
  3. Brian Haberman: Comment [2012-05-16]:
    Just a non-blocking comment that can be resolved easily...
    
    
    
    The Acknowledgments section appears to be incomplete.  The first sentence looks
    
    fragmented, maybe an editing mistake?
  4. Martin Stiemerling: Comment [2012-06-04]:
    no objection if this draft is really going for informational (as listed in the
    
    draft) and not as Standards Track as listed in the datatracker.
  5. Sean Turner: Comment [2012-06-05]:
    I have no objection to the publication of this document as an Informational RFC.

draft-ietf-tcpm-tcpmss

  1. Benoit Claise: Comment [2012-06-06]:
    I don't understand what we gain by having this statement:
    
       Additional clarification was sent to the TCP Large Windows mailing
    
       list in 1993 [Borman93].
    
    
    
    The goal can't be to acknowledge the person who posted the email, as this is the
    
    author ;-)
    
    And it's even confusing. Should I review this email on the top of the
    
    document. This can't be, right?
    
    
    
    Note: that's the first time I see, part of a RFC, a reference to a specific
    
    email in the archive
    
    
    
    Regards, Benoit.
  2. Adrian Farrel: Comment [2012-06-02]:
    I am surprised about the perceived need to update an obsoleted RFC, but
    
    if folk really want to do it, I think they should make it very clear in
    
    this document that RFC 2385 has been obsoleted by RFC 5925 so that
    
    readers understand that using RFC 2385 with the correction documented
    
    here is not the preferred approach.
    
    
    
    ---
    
    
    
    Would a reference to RFC 6151 help?
  3. Russ Housley: Comment [2012-06-01]:
    
      Please consider the editorial comments in the Gen-ART Review by
    
      Martin Thomson on 24-May-2012.  Please find the review here:
    
      http://www.ietf.org/mail-archive/web/gen-art/current/msg07452.html
  4. Barry Leiba: Comment [2012-06-05]:
    Substantive comments; these are non-blocking, but please consider them
    
    seriously, and feel free to chat with me about them:
    
    
    
    In addition to Adrian's comment...
    
    
    
    -- 8 --
    
    At least RFC 879 and RFC 2385 should be normative references here.  It's
    
    kind of hard to imagine how this can Update those, and not cite them
    
    normatively.  (Don't make the mistake of thinking that Informational documents
    
    don't have normative references.)
  5. Martin Stiemerling: Comment [2012-06-04]:
    The abstracts seems to be rather short in order to give hints to  a reader,
    
    i.e., it would be good to the part of IP options and TCP MSS from the into.
  6. Sean Turner: Comment [2012-06-05]:
    Just a reminder to publish a version that incorporates changes agreed to as part
    
    of the secdir review.

draft-ietf-mile-template

  1. Benoit Claise: Discuss [2012-06-05]:
    
    Extending on Adrian's point: I would be glad if you discussed with the Ops ADs
    
    the need to include a
    
    section in Extensons I-Ds covering Manageability
    
    Considerations for the
    
    extensions.
    
    
    
    While I understand that not all extensions have management and operational
    
    considerations, a way forward could be a new manageability section that would
    
    contain something such as:
    
    If an extension implies some operational and
    
    management considerations such as defined in RFC5706 appendix A, then those
    
    considerations must be covered in this section"
    
    
  2. Benoit Claise: Comment [2012-06-05]:
    - shouldn't you reference draft-ietf-mile-iodef-xmlreg-01?
    
    - section 2 "A non-
    
    exhaustive list of good candidate extensions to IODEF includes:"
    
    This sentence
    
    really looks like you're proposing new work. Could you change it to something
    
    such as "a few examples ..."
    
    -  class extension through AdditionalData and
    
    RecordItem elements,
    
           as per section 5.2 of [RFC5070]
    
    s/and/or
    
    - section
    
    A.6 and A.7. It seems that you redo the RFC editor document here. This is
    
    confusing.
  3. Adrian Farrel: Comment [2012-06-01]:
    Thank you for this document I have no objeciton to its publication.
    
    
    
    Here are a few minor and non-blocking Comments that I would appreciate you
    
    reading before publication is complete.
    
    
    
    ---
    
    You will need to remove the citaiotn notation ([ ]) from the Abstract.
    
    --
    
    You should clean up the unused reference to RFC 3339.
    
    ---
    
    I would be glad if you discussed with the Ops ADs the need to include a
    
    section in Extensons I-Ds covering Manageability Considerations for the
    
    extensions.
    
    ---
    
    I found the nesting of appendixes a little perturbing, but it is 
    
    probably easy enough to grok.
  4. Russ Housley: Comment [2012-06-01]:
    
      Please consider the editorial comments in the Gen-ART Review by
    
      Peter Yee on 26-May-2012.  Please find the review here:
    
      http://www.ietf.org/mail-archive/web/gen-art/current/msg07455.html
  5. Robert Sparks: Discuss [2012-06-05]:
    
    In a Last-Call discussion, the author agreed with a comment made by Peter Saint-
    
    Andre that the reference to RFC6545 should be informational, but that change has
    
    not yet been made.
    
    
    
    It should be made more obvious that the examples in Appendix B are examples, and
    
    not actual registrations. Using a real protocol for the example is hazardous.
    
    Could you replace the first example (ENUM) with something clearly not real?
    
    (btw, RFC6116 defines e164.arpa.)
    
    
    
    Can you provide a reference into the existing IODEF specifications for where the
    
    kind of extension discussed in item 3 of section 3 is anticipated?
    
    
  6. Robert Sparks: Comment [2012-06-05]:
    Peter's Last-Call comments also included some editorial suggestions. I would
    
    like to amplify his first comment on being very clear when the use of these
    
    templates (and the guidance around the selection of a namespace value)  are
    
    appropriate.

draft-levine-application-gzip

  1. Adrian Farrel: Comment [2012-06-06]:
    I have no objection to the publication of this document.
    
    
    
    Please check zlib/Zlib/ZLIB for consistency
  2. Stephen Farrell: Comment [2012-06-06]:
    Are the contact points for these registrations ok?  The template
    
    calls for a person/email address, but both give URLs:
    
    http://www.zlib.net/ and http://www.gzip.org which is fine
    
    information but perhaps not what's needed?
  3. Brian Haberman: Comment [2012-06-05]:
    I have no problem with the publication of this document.  I have one editorial
    
    nit that you may take or leave as you see fit.
    
    
    
    - The cross referencing notation of "Section [blah]" is confusing given that it
    
    uses short-hand names for sections.  Please consider changing these to "Section
    
    #" style notation.

draft-irtf-rrg-ilnp-arp

  1. (none)

draft-irtf-rrg-ilnp-v4opts

  1. Stewart Bryant: Comment [2012-05-31]:
    
    Thank you for addressing my discuss items.
    
    
    
    I would like to suggest  that the authors verify that the IPv4 routers in their
    
    test network forward packets containing options with adequate performance before
    
    they invest significant time in the IPv4 Option approach.
  2. Ralph Droms: Comment [2012-05-30]:
    Thank you for publishing draft-irtf-rrg-ilnp-v4opts-05.txt, which revises the
    
    specification to use the IPv4 experimental option code.
    
    
    
    I have two minor editorial comments:
    
    
    
    In Figure 1, the option length fields should be "OL=20" and "OL=12".
    
    
    
    In Figure 3, the option length field should be "OL=12".
  3. Adrian Farrel: Comment [2012-05-23]:
    I agree with Stewart's Discuss stating that there is no need to allocate
    
    IPv4 options for this experiment since it can be run on existing 
    
    experimental options.
    
    
    
    The authors give a reason why using the existing values would
    
    not meet their requirements. I dispute the reason as follows:
    
    
    
    >  In order to experiment with a new protocol, an experimental value may
    
    >  be needed that won't collide with an existing or future usage.
    
    
    
    It is precisely the nature of experiments that they may colide if they are 
    
    run in overlapping networks. There are sufficient code points available 
    
    that this can be coordinated if there are multiple experiments. There are
    
    no existing experiments that immediately spring to mind. Future
    
    experiments will be less likely as IPv4 is sunsetted.
    
    
    
    ---
    
    
    
    The LISP documents (currently in the RFC Editor Queue for publication
    
    as Experimental RFCs in the IETF Stream) have clear and unambiguous
    
    text to caution the user about the unknown side-effects of conducting
    
    the experiment on the Internet. For example, draft-ietf-lisp-23 says:
    
    
    
       This experimental specification has areas that require additional
    
    experience and measurement.  It is NOT RECOMMENDED for deployment
    
       beyond
    
    experimental situations.  Results of experimentation may lead
    
       to
    
    modifications and enhancements of protocol mechanisms defined in
    
       this
    
    document.  See Section 15 for specific, known issues that are in
    
    need of further work during development, implementation, and
    
       experimentation.
    
    
    
       An examination of the implications of LISP on Internet traffic,
    
       applications, routers, and security is for future study.  This
    
       analysis will explain what role LISP can play in scalable routing and
    
       will also look at scalability and levels of state required for
    
       encapsulation, decapsulation, liveness, and so on.
    
    
    
    It seems to me highly desirable that similar caveats be applied to this
    
    work and added to the front of all ILNP documents. I strongly urge the
    
    authors and IRSG to apply such text.

draft-irtf-rrg-ilnp-icmpv4

  1. Stewart Bryant: Comment [2012-05-31]:
    Thank you for addressing my concerns.
  2. Adrian Farrel: Comment [2012-05-30]:
    I have cleared my Discuss on the basis of the new revision to this document.
    
    Thanks to the authors for moving to an experimental code point for this work.
    
    
    
    ---
    
    
    
    The LISP documents (currently in the RFC Editor Queue for publication
    
    as Experimental RFCs in the IETF Stream) have clear and unambiguous
    
    text to caution the user about the unknown side-effects of conducting
    
    the experiment on the Internet. For example, draft-ietf-lisp-23 says:
    
    
    
       This experimental specification has areas that require additional
    
    experience and measurement.  It is NOT RECOMMENDED for deployment
    
       beyond
    
    experimental situations.  Results of experimentation may lead
    
       to
    
    modifications and enhancements of protocol mechanisms defined in
    
       this
    
    document.  See Section 15 for specific, known issues that are in
    
    need of further work during development, implementation, and
    
       experimentation.
    
    
    
       An examination of the implications of LISP on Internet traffic,
    
       applications, routers, and security is for future study.  This
    
       analysis will explain what role LISP can play in scalable routing and
    
       will also look at scalability and levels of state required for
    
       encapsulation, decapsulation, liveness, and so on.
    
    
    
    It seems to me highly desirable that similar caveats be applied to this
    
    work and added to the front of all ILNP documents. I strongly urge the
    
    authors and IRSG to apply such text.