IESG Narrative Minutes

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

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

Corrections from:

1 Administrivia

  1. Roll Call 1135 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. Internationalized Delivery Status and Disposition Notifications (Proposed Standard)
    draft-ietf-eai-rfc5337bis-dsn-04
    Token: Pete Resnick
    Discusses/comments (from ballot 3650):
    1. Adrian Farrel: Comment [2011-10-18]:
      I would like to see Appendix A consolidated to show "Changes from RFC 5337" and retained in the document.
    2. Peter Saint-Andre: Comment [2011-10-19]:
      UPDATED.
      Section 4 mentions that "three new media types are needed". In fact these media types are already defined in RFC 5337 and registered with the IANA. Please consider deleting the word "new".
      Placing normative text in the IANA Considerations (Section 6.1) seems sub-optimal, despite the fact that it was done this way in RFC 5337.
    3. Sean Turner: Comment [2011-10-16]:
      #1) Do the authors wish to also move RFC 5337 to historic?
      #2) s4: r/just <text> Also/just <text>. Also ?
      #3) a.1: Is the note to the rfc-editor to just delete A1. Keeping A.2 (renumbered to A.1 after the existing A.1 is deleted) would help implementers know what's changed.

    Telechat:

  2. SMTP Extension for Internationalized Email (Proposed Standard)
    draft-ietf-eai-rfc5336bis-14
    Token: Pete Resnick
    Note: Note that this document has 2 DownRefs to Informational documents: [RFC4952bis] and [RFC2033].
    Discusses/comments (from ballot 3651):
    1. Jari Arkko: Comment [2011-10-20]:
      There are id nits...
    2. Adrian Farrel: Comment [2011-10-18]:
      It would be nice to condense Section 7 into "Changes from RFC 5336" and retain it in the document.
      I could not parse the Note in Section 1 well enough to understand where the keyword to replace "UTF8SMTPbis" will actually be defined. It is possible that [RFC5336bis-SMTP] is the intended document, however, it is not mentioned anywhere in this I-D.
      A way to handle this might be to put in some real (i.e. not a note to be removed) text that makes a normative reference. Such as:
      "The keyword UTF8SMTPbis is defined in [RFC5336bis-SMTP]."
      You would also need to add a normative reference to [RFC5336bis-SMTP] When the note is acted on, this text will become correct.
      I am hoping that the Responsible AD understands this issue well enough to explain it to the RFC Editor.
    3. Russ Housley: Comment [2011-10-20]:
      Please consider this editorial comment from the Gen-ART Review by Pete McCann on 17-Oct-2011:
      Section 3.6:
      "The message being sent via the MAIL command with the UTF8SMTPbis parameter has still a chance of that the message transmitted is not an internationalized message."
      SHOULD BE:
      "There is still a chance that a message being sent via the MAIL command with the UTF8SMTPbis parameter is not an internationalized message."
    4. Pete Resnick: Comment [2011-10-13]:
      Editorial comment that should be taken care of with the rest of Last Call comments: In 3.2 and 3.6, references to 2045 and 2047 are sometimes just poorly worded and sometimes incorrect. For example, in 3.2:
      "If the UTF8SMTPbis SMTP extension is not offered by the SMTP server, the UTF8SMTPbis-aware SMTP client MUST NOT transmit an internationalized email address and MUST NOT transmit a mail message containing internationalized mail headers as described in [RFC5335bis] at any level within its MIME structure [RFC2045] and [RFC2047]."
      The last bit should simply be "within its MIME [RFC2045] structure". There should be no reference to 2047 here. See also section 3.6.
    5. Peter Saint-Andre: Comment [2011-10-19]:
      It would be helpful to cite RFC 3629 in Section 1.1.
      It is nice that Section 1.1 says "this specification replaces an earlier, experimental, approach to the same problem [RFC5336]." It would be even nicer to describe the results of the experiment and the resulting protocol differences (probably in an Appendix).
      Section 3.2 states: "Any domain name to be looked up in the DNS MUST allow for [RFC5890] behavior." I don't understand what this means, and I find the use of the passive voice confusing here. Does this mean than an SMTP server advertising support for the UTF8SMTPbis extension MUST accept DNS domain names that conform to RFC 5890? If so, let's say that directly.
      Section 3.2 states: "it may choose its own way to deal with this scenario according to the provisions of [RFC4409] or its future versions." Do we mean "MAY"?
      Section 3.5 states: "A UTF8SMTPbis-aware SMTP client MUST only send an internationalized message to an SMTP server that supports UTF8SMTPbis." I think it would be clearer to say "A UTF8SMTPbis-aware SMTP client MUST NOT send an internationalized message to an SMTP server that does not support UTF8SMTPbis."
      Section 5 states: "Another security aspect to be considered is related to the ability by security team members to quickly understand, read and identify email addresses from the logs, when they are tracking an incident." Because reading and understanding an email address would require the person to be capable of reading the script and understanding the language, I think "identify" is all we can hope to promise here (and even that is unlikely in some situations given the existence of confusable characters).
    6. Robert Sparks: Discuss [2011-10-18]:
      As Pete notes in the tracker, the document currently has downrefs for 2033 and 4952bis. To keep these, 3967 currently requires explicitly calling these out as part of Last Call, which I don't think has happened.
    7. Robert Sparks: Comment [2011-10-18]:
      When the changes section gets removed, the hint of what happened to the appendix in 5336 that updated 4952 goes with it. Would it be easy to add a short note somewhere letting the reader know to go look for that in 4952bis?
    8. Sean Turner: Comment [2011-10-16]:
      #1) Do the authors also wish to make RFC 5336 Historic?
      #2) Please add a section that lists the difference between RFC 5336 and this document.

    Telechat:

  3. Internationalized Email Headers (Proposed Standard)
    draft-ietf-eai-rfc5335bis-12
    Token: Pete Resnick
    Discusses/comments (from ballot 3652):
    1. Jari Arkko: Comment [2011-10-20]:
      Ari Keränen helped me review this, and he said:
      Should state in the abstract that this obsoletes and updated various RFCs.
      3. Changes to Message Header Fields: "Also note that messages in this format require the use of the &UTF8SMTPbis;"
      The "&UTF8SMTPbis;" looks like a processing error.
      3.4. Effects on Line Length Limits: "Section 2.1.1 of [RFC5322] limits lines to 998 characters and recommends that the lines be restricted to only 78 characters. This specification changes the former limit to 988 octets."
      What is the rationale behind the 988 octet limit?
    2. Ralph Droms: Discuss [2011-10-20]:
      The nit-checker indicates several problems that need to be fixed before publication, including some missing and incorrect references (which is why I'm recording this issue as a Discuss).
      This document includes a normative reference to an Informational draft, which is not mentioned in the IESG Writeup and apparently not mentioned in the last call text as required by RFC 3967.
    3. Adrian Farrel: Comment [2011-10-18]:
      It would be nice to concentrate section 7 into "changes from RFC 5335" and retain it in the document.
    4. Stephen Farrell: Comment [2011-10-16]:
      Almost a total nit but p7 says "If this type is sent to a 7-bit only system, it has to have..." - to what does the "it" refer the emitter of the message or the 7-bit only system? Also - wouldn't saying "<someone> MUST do <something>" not be clearer than saying "has to have"
    5. Russ Housley: Discuss [2011-10-20]:
      The Gen-ART Review by Miguel Garcia on 18-Oct-2011 points out that this document includes two normative downrefs. I do not see either of these downrefs in the Last Call for this document:
      ** Downref: Normative reference to an Informational draft: draft-ietf-eai-frmwrk-4952bis
      ** Downref: Normative reference to an Informational RFC: RFC 5598
    6. Russ Housley: Comment [2011-10-20]:
      The title page header indicates that this document obsoletes RFC 5335. Please add this fact to the abstract.
      The title page header indicates that this document updates RFC 2045. Please add this fact to the abstract.
      The title page header indicates that this document updates RFC 5322. Please add this fact to the abstract.
    7. Sean Turner: Comment [2011-10-16]:
      #1) Do the authors also wish to make RFC 5335 Historic?
      #2) Please add a section that lists the difference between RFC 5335 and this document.

    Telechat:

  4. DNAME Redirection in the DNS (Proposed Standard)
    draft-ietf-dnsext-rfc2672bis-dname-24
    Token: Ralph Droms
    Note: Andrew Sullivan (ajs@shinkuro.com) is the Document Shepherd.
    Discusses/comments (from ballot 3831):
    1. Ron Bonica: Discuss [2011-10-19]:
      The document header and abstract contradict each other. The header says that this document obsoletes RFC 2672 and updates RFCs 3363 and 4294. The abstract says "This is a revision to the original specification in RFC 2672 as well as updating RFC 3363 and RFC 4294 to align with this revision.
    2. Ron Bonica: Comment [2011-10-19]:
      It would be useful if you added an appendix that summarizes the changes to DNAME and CNAME between this document and previous documents.
    3. Adrian Farrel: Comment [2011-10-17]:
      I would have liked to see a section that summarised "Changes from RFC 2672". (cf. Sean)
      It wouldn't hurt to name the registry in Section 7
    4. Stephen Farrell: Comment [2011-10-11]:
      - in 2.4 would s/must be involed/MUST be invoked/ be better?
      - in 5.3.4.3, last sentence would s/The validator must verify/The valiator MUST verify/ be better?
    5. Russ Housley: Discuss [2011-10-20]:
      The Gen-ART Review by Ben Campbell on 7-Jun-2011 includes:
      This draft does not seem to be quite ready for publication, in that it professes to obsolete RFC 2672, but does not cover all the material from that RFC or explain the absence of the missing material.
      -- Section 4.2 of RFC 2672, "Processing by Resolvers", is not replicated in this draft or it is in a very different form.
      -- Section 5 of RFC 2672, "examples of use" is not replicated in this draft. Similar examples are mentioned in the introduction, but the detail is removed.
      Two revisions of this document have been posted since this review, but the issue has not been addressed. I think it is best resolved by the addition of a section that covers the changes since RFC 2672.
    6. Russ Housley: Comment [2011-10-20]:
      The Abstract says: "This is a revision of the original specification in RFC 2672, also aligning RFC 3363 and RFC 4294 with this revision."
      The title page header indicates that this document obsoletes RFC 2672, and updates RFC 3363 and RFC 4294. Please explicitly state this situation.
    7. Pete Resnick: Comment [2011-10-09]:
      [Probably tilting at a windmill, but...]
      I don't think 2119 language is correctly used when talking about whether a server "SHOULD" load a zone. See section 2.4 and the last paragraph of section 3.3 and compare section 6 of 2119. Not a hill I'm prepared to die on, but I would really like to see this text change.
    8. Peter Saint-Andre: Comment [2011-10-19]:
      In Section 1, might the sentence about "punycode alternates for domain spaces" benefit by citing RFC 3492? The same is true for Section 5.1.
      Section 2.1 has "class-sensitive" -- is "case-sensitive" meant here?
      Section 2.1 has "must be sent in uncompressed form" -- is MUST meant here?
      Section 2.4 notes that "A server SHOULD refuse to load a zone that violates these rules." Are there particular circumstances under which it is acceptable to violate this SHOULD?
      The "Requirements Language" boilerplate text after the Abstract does not include "NOT RECOMMENDED", but Section 4 includes that term; please add it to the boilerplate (this will be accepted by the RFC Editor).
    9. Sean Turner: Comment [2011-10-13]:
      #1) Many times when a document obsoletes another there's a section in the new document that summarizes what's changed. Such a section would be nice to have in s1.

    Telechat:

  5. Using DNS SRV to Specify a Global File Name Space with NFS version 4 (Proposed Standard)
    draft-ietf-nfsv4-federated-fs-dns-srv-namespace-09
    Token: David Harrington
    Discusses/comments (from ballot 3931):
    1. Jari Arkko: Discuss [2011-10-20]:
      I do not understand why the document prohibits the use of DNS-SD to discover NFSv4 services. If I don't have a DNS server in my home network and I want to access information from a NFSv4 capable server, it should work, no?
    2. Jari Arkko: Comment [2011-10-20]:
      I'm not sure why the mount point conventions are needed.
    3. Ralph Droms: Discuss [2011-10-18]:
      This document proposes the use of SRV records for mapping of names of the form <domainroot-service>.<domain> to a mounted filesystem in an NFS client namespace. My review is based on two reviews from the DNS Directorate and my own reading of the document.
      1. The service name specified for the "domainroot" function are a two label name "_nfs._domainroot." and a three label name "_nfs._write._domainroot." As I understand the use of these two service names, they identify two unique, related services for NFS clients. Based on the use of these service names described in this document, there is no need for multi-label service names, and the specification could be simplified by using, e.g., "_nfs-ro." and "_nfs-rw." for the service names.
      2. If there is some expectation for future service sub-types for NFS-related service names, it would be appropriate to define a "_nfs." service with, e.g., "_domainroot-ro." and "_domainroot-rw." subtypes. In this case, the names for read-only and read-write domain roots would be:
      _domainroot-ro._nfs._tcp.example.com
      _domainroot-rw._nfs._tcp.example.com
      3. In section 4: "This DNS SRV record evaluation, could in principle, be done either in the NFSv4 client or in the NFSv4 server....."
      Only the NFSv4 client can perform the DNS resolution as it may have a different resolution context than the server in split DNS scenarios.
    4. Ralph Droms: Comment [2011-10-18]:
      1. To make sure I'm understanding the use of this SRV RR, is it intended to provide information about the root of an NFS file system published as the "uniform file name space" for an organization? Although the target field of the RR could point to any NFSv4 file server, by convention as defined in this document, the target is the root of this "uniform file name space."
      2. Section 4.2 Paragraph 5:
      One of the main points of SRV records is to allow the usage of different ports on servers for provision of service I would like to see the example here use other port than 2049 in at least one example. Or does the NFSv4 specification say "YOU MUST ONLY USE PORT 2049"?
      3. In order to facilitate the provision of both R/O and R/W copies of the same mount point, in theory the Priority field can be used. Lowest priority field is RO, RW are higher priority. This document would give advice on Priority ranges to use for different kinds of systems.
      Example:
      0.10 Read-only
      100..110 Read/Write copies
      10000..10010 Fresh Read/Write copies
      Thus only clients that know what kind of copy they need will use the appropriate subset of SRV records when selecting a server. In this case different sever ports would provide the different access, not different external names.
      Example:
      _nfs._tcp SRV 0 1 45503 BigServer.example.net.
      _nfs._tcp SRV 0 2 2049 SmallServer.example.net.
      _nfs._tcp SRV 101 1 49934 BigServer.example.net.
      _nfs._tcp SRV 10010 3 2049 Backend.example.net.
      Due to the way how records are selected (if RFC2782 selection algorithm is followed) the probability of using high priority servers by read-only clients is quite low.
      4. It might not be a bad idea if the draft analyzed the likely effects of split-brain, DNS64, and so on, but I'm not sure it's necessary.
      5. Assuming IANA is being asked to register these service names in the Service Name and Transport Protocol Port Number Registry [RFC6335], it would be helpful to identify the registry explicitly and cite RFC 6335 in section 7.
      Comments 6, 7 and 8 are related to NFS rather than the SRV record defined in this document.
      6. The convention of using /domainroot-example.net and /.domainroot-example.net for the read-only and read-write versions of the example.net file system is not intuitive to me. Why use the "." prefix rather than, say, /domainroot-ro_example.net and /domainroot-rw_example.net?
      7. Similarly, why use the "." convention for mounting the filesystem in the client?
      8. Are the details of the integration process sketched in section 5 written down in more detail somewhere else? In my opinion, I'm not sure section 5 will ensure a uniform use of the SRV record across all clients.
    5. Adrian Farrel: Comment [2011-10-04]:
      "The NFS version 4 protocol provides a natural way for a collection of NFS file servers to collaborate in providing an organization-wide file name space."
      I love "natural." Is that just using herbal essence, or do you also use crystals?
      Section 3 might be a bit more definitive. No need to "propose" things in a published RFC.
    6. Russ Housley: Discuss [2011-09-30]:
      The Gen-ART Review by David Black on 26-Sept-2011 raises some concerns that deserve a response.
    7. Pete Resnick: Comment [2011-10-05]:
      I agree with the concerns regarding the SRV record and the mount points.
    8. Peter Saint-Andre: Discuss [2011-10-03]:
      I concur with the DISCUSS raised by Russ Housley in reference to the Gen-ART review: as far as I can see, a Service name of "_nfs4._domainroot" is not consistent with RFC 2782. If indeed the WG has formulated a solution to that problem ("in the form of a unitary single-level service name"), and if the WG has consensus on that proposed solution, then the I-D should be revised to incorporate that solution. Until that is done (or some other solution is found), I do not think it is appropriate to advance this specification to Proposed Standard.
    9. Robert Sparks: Discuss [2011-10-04]:
      I expect to clear or revise this discuss quickly based on discussion:
      It's unusual to standardize a directory name in a host's filesystem namespace (see section 4.1). Has the IETF done this before? Is it the right organization to establish this kind of convention?
    10. Robert Sparks: Comment [2011-10-04]:
      I support Peter's discuss.
    11. Sean Turner: Comment [2011-10-04]:
      s4.2: r/recommended/RECOMMENDED in the following:
      "As for the other attributes in fs_locations_info, the recommended approach is for a client to make its first possible contact with any ..."

    Telechat:

  6. Time to Remove Filters for Previously Unallocated IPv4 /8s (BCP)
    draft-ietf-grow-no-more-unallocated-slash8s-04
    Token: Ron Bonica
    Note: Chris Morrow (christopher.morrow@gmail.com) is the document shepherd.
    Discusses/comments (from ballot 3944):
    1. Wesley Eddy: Comment [2011-10-18]:
      Support Stephen's DISCUSS and agree with Adrian's COMMENT.
    2. Adrian Farrel: Comment [2011-10-17]:
      If there are no more unallocated /8s, I cannot understand how a filter for unallocated /8s would be in any way a problem.
      The second paragraph of the Abstract and the Introduction is, therefore, confusing.
      I think this could be clarified in terms of the language in the first paragraph about "unallocated address space." Or you could use the language of section 3.2.
    3. Stephen Farrell: Discuss [2011-10-17]:
      discuss discuss
      Should this wait on, and reference, the potential /10 allocation of draft-weil-shared-transition-space-request assuming that that /10 is approved?
    4. Pete Resnick: Comment [2011-10-18]:
      Windmill tilt: I see no reason that this can't be a Proposed Standard in that it is giving implementation advice.

    Telechat:

  7. The RPKI Ghostbusters Record (Proposed Standard)
    draft-ietf-sidr-ghostbusters-15
    Token: Stewart Bryant
    Note: Chris Morrow (morrowc@ops-netman.net) is the document shepherd.
    Discusses/comments (from ballot 3945):
    1. Jari Arkko: Comment [2011-10-20]:
      This document could only have been written by Randy :-)
    2. Adrian Farrel: Comment [2011-10-16]:
      As you will be aware (having read RFC 5513) it is hard to find a previously unused three letter combination. I don't think there are any issues with using the .gbr filename extension, but be aware that it is also used by gimp graphics package.
    3. Stephen Farrell: Comment [2011-10-11]:
      1) I originally had a discuss saying:
      "I don't see how I'd actually find the ghostbuster record say starting from a CRL or cert or signed object that I think may be (about to be) problematic. That's probably really clear to rpki folks but from just reading this I don't get it, and given the purpose of the record it might be worth saying something in the document. I'm sure I'll clear once someone provides the (probably obvious;-) answer."
      That was answered quickly by Randy saying: "from the object, go up to the CA cert, which may be the object itself, of course. that cert has an SIA to the publication point where all subsidiary objects (until you hit a down-chain CA cert's signed objects) are published. the publication point will contain zero or more gbrs."
      I reckon it'd be good to say something like that in the doc as well.
      2) Is it considered acceptable to not put a person's name in the FN field of the record but rather a role, e.g. "shit/fan separator" or the polite equivalent? If that's considered ok, maybe pointing it out would be good. If not, then perhaps emphasise that the FN must be the name of a real person but then I wonder how this is maintained when the current shit/fan separator goes on vacation or gets fired.
    4. Russ Housley: Comment [2011-10-17]:
      Please consider the comments from the Gen-ART Review from Miguel Garcia on 19-Sep-2011.
    5. Pete Resnick: Comment [2011-10-09]:
      I was left a bit confused about what precisely is *the* Ghostbusters Record. I got lost as to what was the record, and what was the payload of the record. It would have helped me if in addition to, "The Ghostbusters Record conforms to the syntax defined in [I-D.ietf-sidr-signed-object]", you would have added the sentence "The payload of this signed object is a severely profiled vcard", and maybe having something in the "Additional Information" in the media type registration that it is the SIDR signed-object, not the vcard data, that is being defined as the media type. Maybe folks who work in this space would not have gotten confused, but as random MIME schmo, it took me going back and forth a few times to be clear on what was what.

    Telechat:

  8. The Multipart/Report Media Type for the Reporting of Mail System Administrative Messages (Draft Standard)
    draft-ietf-appsawg-rfc3462bis-02
    Token: Pete Resnick
    Discusses/comments (from ballot 3946):
    1. Ron Bonica: Comment [2011-10-19]:
      Concur with Russ' discuss.
    2. Adrian Farrel: Comment [2011-10-18]:
      Cleared my Discuss after discussion
    3. Russ Housley: Discuss [2011-10-17]:
      This should be going to Internet Standard under the new process.
    4. Robert Sparks: Discuss [2011-10-18]:
      I encourage advancing this under RFC6410.
      That change to the process no longer _requires_ an implementation report, but since this was originally intended for publication as Draft standard, I assume one's been put together? I'm not finding it at <http://www.ietf.org/iesg/implementation-report.html> and it would be a shame to lose it if it's already done.
    5. Sean Turner: Discuss [2011-10-18]:
      Updated based on -02.
      <process weenie>
      #1) The authors are contacting the authors of 3462 - so I this is really just a placeholder discuss until the 3462 authors says yes/no and the boilerplate gets left alone/changed.
      I'm hoping the answer to this is yes, but I had to ask because I didn't see it in the proto write-up:
      This document doesn't have a pre-5378 disclaimer and the author set is not the same as RFC 3462. Did Gregory grant the rights to the IETF Trust to allow the document to be published without the pre-5378 disclaimer?
      #2) addressed in -02
      #3) cleared
      </process weenie>
    6. Sean Turner: Comment [2011-10-18]:
      #1) Do the authors also wish to make RFC 3462 and or 1892 Historic?
      #2) I'll leave it to Pete/Barry if the additions as a result of discuss #2 require coordination with ietf-types@ietf.org

    Telechat:

  9. LSP Attributes Related Routing Backus-Naur Form (Proposed Standard)
    draft-ietf-ccamp-attribute-bnf-02
    Token: Adrian Farrel
    Note: Deborah Brungard (dbrungard@att.com) is the Document Shepherd.
    Discusses/comments (from ballot 3960):
    1. Russ Housley: Comment [2011-10-20]:
      I want to build on two comments that were originally offered in the Gen-ART Review by Vijay Gurbani on 17-Oct-2011.
      Section 2 includes an group of indented paragraphs, and all but one of those paragraphs contains an RFC 2119 key word. Please consider making the "must" in that paragraph into "MUST".
      Section 3 includes an group of indented paragraphs, and all but one of those paragraphs contains an RFC 2119 key word. Please consider making the "must" in that paragraph into "MUST".

    Telechat:

  10. MPLS Transport Profile lock Instruct and Loopback Functions (Proposed Standard)
    draft-ietf-mpls-tp-li-lb-07
    Token: Adrian Farrel
    Note: Loa Andersson (loa@pi.nu) is the document shepherd.
    IPR: Cisco's Statement of IPR related to draft-ietf-mpls-tp-li-lb-00
    Discusses/comments (from ballot 3971):
    1. Ron Bonica: Comment [2011-10-20]:
      Please run the spell checker over this document.
    2. Stephen Farrell: Comment [2011-10-17]:
      - It seems that the LI message allows setting a timer so that repeat LI messages only need to be sent every 255 seconds, and one of those every ~15 minutes (255*3.5) would keep a locked section locked. Would it be worth nothing this potential DoS in the security considerations, since that's quite a good return for the putative attacker in terms of bits sent by the attacker vs. bits not sent due to the DoS?
      - NMS is used but not expanded/defined
      - s/despatch/dispatch/?
      - s/must e/must be/
      - s/either end/both ends/ would be better in 6.2, 1st para
    3. Sean Turner: Comment [2011-10-17]:
      s1.1: Is it update or replace s7.1.1? I guess it really doesn't matter, but if the intent is really to completely replace then maybe it'd be clearer to just say that. Also, s6.2 of this draft discusses unlocking and s7.1.2 discussed unlocking so shouldn't s1.1 of this draft also point out that 7.1.2 is also updated/replaced?
      s2.2: RFC 6371 uses LKI for Lock Instruction instead of LI. Are there other MPLS RFCs/I-Ds that use LKI instead of LI? Just trying to make sure they're all lined up nicely.
      s2.2: add: "NMS Network Management System"
      s4.1: r/This possible for/This is possible for ?
      s5.2: Any reason to not start at 0? Seems like you're burning a number.
      s7: Well I'm not so sure it's a security issue, but is there a concern about sending real traffic during a loopback? In other words should you always send some dummy traffic?

    Telechat:

2.1.2 Returning Items

  1. (none)

2.2 Individual Submissions

2.2.1 New Items

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

    Telechat:

2.2.2 Returning Items

  1. (none)

3. Document Actions

3.1 WG Submissions

3.1.1 New Items

  1. (none)

3.1.2 Returning Items

  1. (none)

3.2 Individual Submissions Via AD

3.2.1 New Items

  1. Registration of Military Message Handling System (MMHS) header fields for use in Internet Mail (Informational)
    draft-melnikov-mmhs-header-fields-04
    Token: Pete Resnick
    Discusses/comments (from ballot 3918):
    1. Jari Arkko: Comment [2011-10-20]:
      I agree with the issues raised on the normative reference. These should be available. Also, the document says:
      "Note: There is no guarantee that the exempted addresses will not receive the message as the result of redirection, Distribution List (DL) expansion, etc."
      This is pretty weak language for a military spec. But it is not my army, so....
    2. Adrian Farrel: Comment [2011-10-17]:
      (11 items)
    3. Stephen Farrell: Discuss [2011-10-13]:
      I'm not sure I agree there are no new security considerations here given that these header fields are not protected by S/MIME but are (I think, maybe I remember wrong) signed in X.400 MMHS or ACP <foo>. Am I right there?
      If so with a message like this I could for example delete the MMHS-Exempted-Address header field for example and bad stuff might happen. In that case, you probably need to include some analysis of the potential bad things and might want to RECOMMEND signing with DKIM perhaps.
      If I'm wrong and the equivalent 4406 extensions cannot be signed then I agree there's nothing much new here and will clear.
    4. Stephen Farrell: Comment [2011-10-13]:
      - It seems a bit odd that this is informational - I'd have expected the consumers of this to require a standards track document for it to be really useful to them. But I guess the authors know better.
      - IPMS is used without expansion
      - The ACP 127 reference would be better provided where its first mentioned.
      - What is "the Extensions heading field" in 3.1 and why is the header field called "this extension" here? Is that text leakage from 4406?
      - in 3.2 would s/was submitted/was initially submitted/ be more correct?
      - 3.2 says this one SHOULD be included, might be useful to say these are all OPTIONAL unless otherwise stated?
      - For values like the SIC codes, and others, can you give a reference to relevant registries? That should help someone trying to write code from this.
      - 3.4 says this is "human readable" but the example "ZNY; RRRR" doesn't strike me as Shakespear-like:-) And is there an (open) registry of codes for this?
      - Should you have a reference to how to encode ACP127 in a MIME body in 3.6?
      - In 3.7 what does "would be stripped" mean? Is that really a MUST and if so, for whom?
      - In 3.8 s/shall ensure/MUST ensure/ ?
      - 3.10 calls this one a "heading extension" which seems wrong
      - 3.10 s/may includes/may include/
      - I assume there are no I18N problems with the values that are allowed in all of these fields - is that right?
      - I think you could mention that DKIM could be used to sign these header fields at least.
    5. Russ Housley: Comment [2011-10-20]:
      I think the tone of the Abstract sends the wrong message to the reader. I suggest the following re-write:
      OLD: "A Miltary Message Handling System (MMHS) processes formal messages ensuring release, distribution, security, and timely delivery across national and international strategic and tactical networks. The MMHS Elements of Service are defined as a set of extensions to the ITU-T X.400 (1992) international standards and are specified in STANAG 4406 Edition 2. This document describes a method for enabling those MMHS Elements of Service that are defined as Heading Extension to be encoded as RFC 5322 (Internet Email) message header fields. These header field definitions support the provision of a STANAG 4406 MMHS over Internet Email, and also provides for a STANAG 4406 / Internet Email Gateway supporting message conversion compliant to this specification."
      NEW: "A Miltary Message Handling System (MMHS) processes formal messages ensuring release, distribution, security, and timely delivery across national and international strategic and tactical networks. The MMHS Elements of Service are defined as a set of extensions to the ITU-T X.400 (1992) international standards and are specified in STANAG 4406 Edition 2. This document specifies message header fields and associated processing for RFC 5322 (Internet Email) to provide a comparable messaging service. In addition, this document provides for a STANAG 4406 / Internet Email Gateway that supports message conversion."
    6. Peter Saint-Andre: Comment [2011-10-19]:
      Several reviewers have provided very detailed feedback, so I am restricting my comments to a few small points in the text.
      1. Is MMHS / STANAG 4406 only for communication among NATO member countries? If so, the text in the Abstract and the Introduction over-promises.
      2. Section 1 states: 'The RFC 5322 header fields defined are prefixed with the string "MMHS-" to distinguish them from any other header fields.' Can the "MMHS-" prefix be used in any other header fields, or is the intent that it is being locked down by this specification? For the record, I think the latter approach would be a bad idea and not enforceable by IANA.
      3. In Section 3.8, "MMHS-Primary-Precedence: 7" appears to use a disallowed label.
      4. Section 3.10 has a typo: "MMHS-Message-Type: 2 (projet)"
      5. Given the definition of "integer" in Section 4, +0 and -0 seem to be allowed. Is that correct?
    7. Sean Turner: Discuss [2011-10-16]:
      Despite the length of these I believe a draft that translates MM-header fields to RFC5322-header fields is publishable.
      #1) STANAG 4006 is listed as a normative reference. It's not available on the NATO site (http://www.nato.int/cps/en/SID-8BF0F167-D3248540/natolive/stanag.htm). It was on Graeme's company site, but the link doesn't seem to work. I couldn't find it on other publicly available sites (maybe I didn't look hard enough). I have two questions that I think go to the need for normative references to be publicly available:
      a) Is this document actually publicly/widely available? Assuming it can't be had on the Internet, I know that you can get hard copies IF you contact your NATO-member national body (e.g., UK MoD, USA DoD) (kind of like asking a publisher to give you a copy of a book/article they published - but I don't think these publishers will charge you - not sure about this though). However, how is somebody who lives in a country that is not part of NATO going to get a hard copy? Will NATO respond to queries for STANAG's from people who have non-NATO nationalities or who don't live in NATO member states? I've got not idea - just asking.
      b) Is the version on Graeme's company site official and final? If not shouldn't "draft" appear in the reference?
      If Graeme's site doesn't have active links and NATO won't give it to folks who live in non-NATO countries - is STANAG 4406 really available?
      If STANAG 4406 doesn't seem like a viable reference you could switch the whole thing around to refer to ACP 123 - it's available online.
      #2) I think I might be reading way more in to this than I should, but I think you can't say that by translating these services you're enabling MMHS services in Internet mail. To me that sounds like advertising and I think if that statement was to be made somebody who works for NATO (or maybe a NATO-member nation) would would need to say it. It's like when a draft author claims their draft is Suite B compliant - somebody from the NSA would have to say that not the author (unless they worked at NSA). I think if you're clinical about it - i.e., this document translates from this to this - then you're okay. What follows are the tweak I think you need to make. My intent with the suggested changes is to ensure the information necessary for implementers to implement is still there - and I hope I've done that.
      (snip -- see link)
      #3) I pulled out my handy-dandy copy of ACP 123 and noted that the value range for precedence (primary and copy) as well as message type are entirely reserved for NATO and national use. How will additions be handled? Is the IESG or IANA going to tell non-NATO national entities they can't define values in that space? For example, New Zealand comes along and wants to add "faster than sheep" as a precedence as 6 - what happens?
      #4) I expect this one ought to be cleared on or before the call. s3: I was expecting the header names in the table to match the MM-header fields.
      a) It might not be required but would it just make more sense? For example why wouldn't name MMHS-Subject-Indicator-Codes MMHS-Distribution-Codes and then say in that header's section: we only do SICs?
      b) (I expect there's a really good reason for this one and I just don't know it) Wouldn't it be clearer to just have MMHS-Other-Recipient-Indicator as opposed to splitting it in to MMHS-Other-Recipients-Indicator-To/MMHS-Other-Recipients-Indicator-Cc.
      #5) s5 contains the following text: "A few capabilities have been left out which would have significantly increased the complexity of this specification, and do not appear to be of significant benefit."
      I'm not entirely sure you can say the last bit without an additional qualifier like: (in the eyes of the authors who don't speak for NATO or any nation that's a part of NATO). Unless of course you are? Maybe you can just delete the last bit.
      There's also the second sentences for distribution codes and pilot forwarding info:
      "Distribution extensions are not widely used, and encoding ANY DEFINED BY in this specification would be difficult.
      "This complex extension is only for ACP 127 transition, and is not widely used."
      You know this for absolutely sure? This sounds like you're speaking authoritatively for NATO and I'm not sure you can. You could just list the ones you didn't map and leave it at that.
    8. Sean Turner: Comment [2011-10-16]:
      (25 items, see link)

    Telechat:

  2. Complaint Feedback Loop Operational Recommendations (Informational)
    draft-jdfalk-maawg-cfblbcp-02
    Token: Pete Resnick
    Note: Barry Leiba (barryleiba@computer.org) is the document shepherd
    Discusses/comments (from ballot 3941):
    1. Jari Arkko: Discuss [2011-10-20]:
      It is a good idea to publish this, thank you for bringing it to an internet draft form and the IETF.
      However, I think the copyright disclaimer statements are currently in an unacceptable form. Is this a mistake, or were these settings deliberate? I think we need to discuss this. The document is also internally inconsistent:
      "While not originally written as an Internet Draft, it has been contributed to the IETF standards repository in order to make it easier to incorporate this material into IETF work."
      This document may not be modified, and derivative works of it may not be created, and it may not be published except as an Internet-Draft."
      and yet it is brought to the IETF to incorporate material into IETF work, and to publish as an RFC!
    2. Wesley Eddy: Comment [2011-10-18]:
      There are some characters misaligned in Figure 1 that should be fixed.
      It's probably not right to say "IETF standards repository" in the abstract; I think you really just mean "the RFC Series" or something like that.
    3. Stephen Farrell: Discuss [2011-10-16]:
      It seems wrong to recommend ways to figure out the actual recipient email address from which the complaint originates, when that has been (perhaps badly) redacted by the feedback provider. I doubt such text would be accepted as-is in an IETF WG document.
      Shouldn't the text on p25 ("It can be very difficult to extract...") down to "...and trending analysis).") that hints at how to do that also at least say that doing so is acting contrary to the wishes of such a feedback provider and perhaps the end user that originated the complaint? Or, perhaps you should give some more effective advice to the privacy sensitive end-user or feedback provider? (Which may practically amount to "don't *ever* send feedback";-)
      Note: I'm not asking that the mail industry reform itself and I'm not sure how effective it may be to put a discuss on a document like this, but I'd be much happier if this could be fixed somewhat.
      So I guess the first part of my discuss to think about is: Is there some way to fix this for the IETF version of the document?
    4. Stephen Farrell: Comment [2011-10-16]:
      There are quite a few comments here. Given the provenance of this document, I'm pretty much fine if they're entirely ignored and just offer than as a potential ways to improve the text if doing so is possible at this point in time.
      (22 items)
    5. Russ Housley: Discuss [2011-10-20]:
      Please reword the Abstract to remove the phrase "contributed to the IETF standards repository". Since this is an Informational document, I believe this phrase will be confusing. Suggestion:
      "This document was originally produced by the Messaging Anti-Abuse Working Group (MAAWG), a trade organization separate from the IETF. The original MAAWG document was published in April 2010. This document is being published as an Informational RFC to make it widely available to the Internet community and simplify incorporation of this material into IETF documents."
    6. Pete Resnick: Comment [2011-10-13]:
      There was some last call discussion that indicating that some people found the "About MAAWG" paragraph in the Abstract untoward. Personally, I think it would be better to put the paragraph in the Acknowledgments section, or it could be simply put as a paragraph in the References section under reference [1].
      These are recommendations from MAAWG, and they are being published as an informational, non-consensus document so that a WG can refer to the document. Such a WG may agree with all of the recommendations, but more likely will have some alternative advice when referring to this document. The IESG should decide whether an IESG note explaining this is necessary, but I think the standard template for a non-consensus document ("This document is not an Internet Standards Track specification; it is published for informational purposes. It has been approved for publication by the Internet Engineering Steering Group (IESG).") is probably sufficient.
      I have an RFC Editor note to change the page header from "CFBL BCP" to "CFBL Recommendations". If the authors wish something different, they are free to suggest.
    7. Peter Saint-Andre: Comment [2011-10-19]:
      The definition in Section 1 has one instance of "spam" (all lowercase) but in the remainder of the document aside from Appendix C the only form used is "Spam" (initial caps).
      In Section 3.2, does "proprietary desktop client" exclude open-source implementations?
      In Section 3.5, why not cite RFC 2142? Such as: "best sent to abuse@ or postmaster@ the domain in question, per [RFC2142]".
      Appendix A.2 cites RFC 5965 and two websites as sources of canonical documentation for ARF, one of which points to draft-shafranovich-feedback-report-01 whereas the other points to draft-shafranovich-feedback-report-05. How is a developer to know which specification is in fact canonical? Please just point to RFC 5965 for documentation and to the websites for additional information.
    8. Robert Sparks: Discuss [2011-10-18]:
      This is a discuss-discuss. No action from the editors is requested at this time.
      Pete's comment indicates this is intended to be published as a non-consensus document (even though it's been last called). That would mean 2nd paragraph of boilerplate (per 5741 section 3.2.2) would be: "This document is a product of the Internet Engineering Task Force (IETF). It has been approved for publication by the Internet Engineering Steering Group (IESG)." And would _not_ contain "It represents the consensus of the IETF community."
      Is that the intent? If so, how does that get captured and passed to the RFC Editor?
    9. Sean Turner: Discuss [2011-10-17]:
      <process weenie>
      This draft contains the following restrictions on publication from 6.c.ii of the TLP:
      "This document may not be modified, and derivative works of it may not be created, and it may not be published except as an Internet-Draft."
      I'm thinking you meant to include the text from 6.c.i:
      "This document may not be modified, and derivative works of it may not be created, except to format it for publication as an RFC or to translate it into languages other than English."
      Otherwise, it can't be published as an RFC.
      Need to split references between normative and informative. If they're all one kind just put informative or normative in front of references in the title.
      Needs an IANA Considerations section. If there are none, then the section can simply be:
      "IANA Considerations: "None
      </process weenie>
      Pete: Are you planning on publishing it with this boiler plate:
      "This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG)."
      or this boiler plate:
      "This document is a product of the Internet Engineering Task Force (IETF). It has been approved for publication by the Internet Engineering Steering Group (IESG)."
    10. Sean Turner: Comment [2011-10-17]:
      s*: r/paper/document Normally I-Ds/RFCs use document rather than paper. So much more official ;)
      s1: Complaint Feedback Loop - There isn't a taxonomy section so maybe it should just be "See Overview section." ?
      s1: FBL - I had to chuckle there's an extremely long list of acronyms not used and they got left out - why mention this one? BTW - fbl it's in s4.1 step 2 and in s4.4 ;)
      s*: The concept of the loop is odd in that spammer isn't really going to be in the loop. In fact, you want to get rid of them.
      s2: Uses the term authorized Feedback Consumer. The definition in s1 didn't make any distinction between Feedback Consumers. I guess this my round about way of asking if all Feedback Consumers are authorized?
      s3.3: "keyed to" maybe "assigned to"?
      s3.4.2: r/approved entity/authorized entity - to match s2.
      s3.4.1 & 3.4.2: Often folks quote the Fair Information Practices when dealing with privacy issues. Maybe instead of munging them together in the terms of use you could just list them like:
      - Notice and Consent:
      - Collection Limitation:
      - Use/Disclosure Limitation:
      - Retention Limitation:
      - Accuracy:
      - Access:
      - Security:
      I've got no idea how you'd implement access, because of course spammers want to know what people have said about them. Then again maybe they don't because then you could track them?
      s8: Update references to RFC 4871 to RFC 6376.

    Telechat:

3.2.2 Returning Items

  1. (none)

3.3 IRTF and Independent Submission Stream Documents

3.3.1 New Items

  1. Considerations for Information Services and Operator Services Using SIP (Informational)
    draft-haluska-sipping-directory-assistance-11
    Token: Robert Sparks
    Note: ISE Submission
    Robert Sparks is the 5742 review shepherd
    Discusses/comments (from ballot 3010):
    1. Jari Arkko: Comment [2011-10-20]:
      I'm not sure I understand why a document that says "here's one way of using IETF protocols for <blaah>" and "here are some unmet requirements for <blaah>" can be considered as harmful for an IETF working group, even if that working group is focusing on the same space. I think a note with pointer to the IETF work would be more reasonable reaction in this case.
      But I don't work in this field, so maybe I'm missing something obvious.
    2. Adrian Farrel: Discuss [2011-10-18]:
      As this docuent stands, I support Robert's 5742 review. According to 5742, I think Robert's feedback to the ISE should include the request that the IESG should be allowed to add an IESG note to the document in the event that the ISE decides to publish it.
      I also think it would be helpful (although not required by 5742) to clarify "at this time." Does the IESG forsee a time at which publication would be OK?
    3. Adrian Farrel: Comment [2011-10-18]:
      I suspect that parts of this document could have been acceptable for publication, but the document has tried to do too much and cover too much ground.
      To some extent, this can be seen from the mixed message about the purpose of the document.
      The Abstract says:
      "This document aims to identify how Operator and Information Services can be implemented using existing or currently proposed SIP mechanisms, to identity existing protocol gaps, and to provide a set of Best Current Practices to facilitate interoperability. For Operator Services, the intention is to describe how current operator services can continue to be provided to PSTN based subscribers via a SIP based operator services architecture. It also looks at how current operator services might be provided to SIP based subscribers via such an architecture, but does not consider the larger question of the need for or usefulness or suitability of each of these services for SIP based subscribers.
      "This document addresses the needs of current Operator and Information Services providers; as such, the intended audience includes vendors of equipment and services to such providers."
      But Section 1 says:
      "Implementing Operator and Information Services with SIP will require the exchange of certain information, and possibly the use of specialized capabilities which are not normally required for other types of calls. This document aims to identify such information, and stimulate discussion about how this information could be exchanged. Existing mechanisms will be used where appropriate, and currently existing proposals will be favored over new extensions."
      That is a lot of different purposes, and some of them run flat up against core IETF work as Robert indicates.
      I think that if you had limited yourselves to
      "This document aims to identify how Operator and Information Services can be implemented using existing or currently proposed SIP mechanisms, and to provide a set of Best Current Practices to facilitate interoperability."
      you would probably have found more support for the document and possibly support from within the working group.
    4. Stephen Farrell: Comment [2011-10-17]:
      I agree with the proposed 5742 response, i.e. to recommend not publishing at this time.
      I also have some comments below that the authors might want to take into account.
      - "MF" isn't defined/explained (p6, used twice), as are a bunch of other acronyms (ISUP, TNS, CIP, CSI...). Not sure which need definitions but I guess some at least do.
      - p22 - listening to "a scrambled version" of the call seems odd - is that a real service? what kind of "scrambling"?
      - 2nd last para of p29 says when you've no identity info, you "MAY be unable" to do stuff - would that be better with a "SHOULD or MUST NOT implement" since attempting to do so would presumably go against the caller's wishes or the inter-domain agreements between the various providers?
      - There are many occurrences of phrases like "in North America." (`grep America draft-haluska-* | wc` -> 38; Europe occurs twice and Asia not at all.) So many in fact, that I wonder if the title should be changed to reflect that - this really seems like a North American oriented document. (Having said that, I've no real clue as to whether the actual content is more broadly applicable or not.)
      - Section 9.16 seems to depend on sending an obfuscated URI for the "whisper" audio. That should raise a bunch of security considerations, but those are not addressed, at least in 9.16. There would also be questions as to when that audio can safely be deleted, and potential privacy concerns if it is not promptly deleted that don't seem to be addressed.
      - Title of 9.20 - s/With Holding/Withholding/ and similarly within the body of the section s/with held/withheld/ etc
      - The "intercept-*" sip URIs described in 11.4.1 seem odd. Wouldn't doing that require these to be specially registered in some IANA registry that every SIP UA and other SIP implementation knows about in order to prevent fairly nasty attacks?
      - I didn't read the "collect call" and 3rd party billing things very closely but they seem fairly ripe for fraud. A section showing why this is not the case would seem to be missing, especially as 11.5 says that collect calling could be done without human intervention. I guess I'd start thinking about attacking this by re-routing the RTP streams maybe but the point is that if the authors have thought through the potential for fraud, I'd have expected some text about that.
      - The security considerations basically says "look at the references and the rest is TBD" but in more words;-) That may be ok in a document like this, but its not very satisfactory that the proposed services have been defined down to the level of message flows but with no security analysis being provided.
    5. Pete Resnick: Comment [2011-10-18]:
      I agree with Adrian that we should also ask for the opportunity to include a statement if the ISE decides to publish.

    Telechat:

3.3.2 Returning Items

  1. (none)

1245 EDT break

1250 EDT back

4 Working Group Actions

4.1 WG Creation

4.1.1 Proposed for IETF Review

  1. (none)

4.1.2 Proposed for Approval

  1. Binary Floor Control Protocol Bis (bfcpbis)
    Token: Gonzalo

    Telechat:

  2. Managed Incident Lightweight Exchange (mile)
    Token: Sean

    Telechat:

4.2 WG Rechartering

4.2.1 Under evaluation for IETF Review

  1. (none)

4.2.2 Proposed for Approval

  1. (none)

5. IAB News We can use

6. Management Issues

  1. IESG statement on Historic designation (Russ Housley)

    Telechat:

  2. Note to IAOC from IESG (Russ Housley)

    Telechat:

7. Agenda Working Group News

Adrian: point you at Michelle's email
David: what is the issue?
Adrian: pasted into jabber
Robert: I have another short item
Robert: further work to do
Russ: NFS-one is regular discuss resolution
Robert: gap in the tracker: number of documents where tracker doesn't know which stream: how is it getting set right now
Cindy: WG docments are known to be IETF stream
Russ: others manual by Secretariat
Robert: would it work to have AD set stream at same time as setting status? should be put any significant effort into fill stream-unknown documents?
Russ: level-of-effort question
Robert: for recent documents, not huge but not trivial, multiple days
Russ: does tracker keep telechat agendas for the past -- could you walk through things that appeared in section 2, e.g. -- anything more seems to be diminishing-return
Robert: I think we can only ask which section if it appeared on agenda today
Russ: seems sufficient

1335 EDT Adjourned


Valid HTML 4.01 Strict


Appendix: Snapshot of discusses/comments

(at 2011-10-20 07:30:25 PDT)

draft-ietf-eai-rfc5337bis-dsn

  1. Adrian Farrel: Comment [2011-10-18]:
    I would like to see Appendix A consolidated to show "Changes from RFC 5337" and
    retained in the document.
  2. Peter Saint-Andre: Comment [2011-10-19]:
    UPDATED.
    
    Section 4 mentions that "three new media types are needed". In fact these media
    types are already defined in RFC 5337 and registered with the IANA. Please
    consider deleting the word "new".
    
    Placing normative text in the IANA Considerations (Section 6.1) seems sub-
    optimal, despite the fact that it was done this way in RFC 5337.
  3. Sean Turner: Comment [2011-10-16]:
    #1) Do the authors wish to also move RFC 5337 to historic?
    
    #2) s4: r/just <text> Also/just <text>.  Also  ?
    
    #3) a.1: Is the note to the rfc-editor to just delete A1.  Keeping A.2
    (renumbered to A.1 after the existing A.1 is deleted) would help implementers
    know what's changed.

draft-ietf-eai-rfc5336bis

  1. Jari Arkko: Comment [2011-10-20]:
    There are id nits...
    
  2. Adrian Farrel: Comment [2011-10-18]:
    It would be nice to condense Section 7 into "Changes from RFC 5336" and
    retain it in the document.
    
    ---
    
    I could not parse the Note in Section 1 well enough to understand where
    the keyword to replace "UTF8SMTPbis" will actually be defined. It is
    possible that [RFC5336bis-SMTP] is the intended document, however, it
    is not mentioned anywhere in this I-D.
    
    A way to handle this might be to put in some real (i.e. not a note to
    be removed) text that makes a normative reference. Such as:
       The keyword UTF8SMTPbis is defined in [RFC5336bis-SMTP].
    You would also need to add a normative reference to [RFC5336bis-SMTP]
    When the note is acted on, this text will become correct.
    
    I am hoping that the Responsible AD understands this issue well enough
    to explain it to the RFC Editor.
  3. Russ Housley: Comment [2011-10-20]:
      Please consider this editorial comment from the Gen-ART Review by
      Pete McCann on 17-Oct-2011:
    
      Section 3.6:
        The message being sent via the MAIL command with the UTF8SMTPbis
        parameter has still a chance of that the message transmitted is not
        an internationalized message.
      SHOULD BE:
        There is still a chance that a message being sent via the MAIL
        command with the UTF8SMTPbis parameter is not an internationalized
        message.
  4. Pete Resnick: Comment [2011-10-13]:
    Editorial comment that should be taken care of with the rest of Last Call
    comments: In 3.2 and 3.6, references to 2045 and 2047 are sometimes just poorly
    worded and sometimes incorrect. For example, in 3.2:
    
       If the UTF8SMTPbis SMTP extension is not offered by the SMTP server,
       the UTF8SMTPbis-aware SMTP client MUST NOT transmit an
       internationalized email address and MUST NOT transmit a mail message
       containing internationalized mail headers as described in
       [RFC5335bis] at any level within its MIME structure [RFC2045] and
       [RFC2047].
    
    The last bit should simply be "within its MIME [RFC2045] structure". There
    should be no reference to 2047 here. See also section 3.6.
  5. Peter Saint-Andre: Comment [2011-10-19]:
    It would be helpful to cite RFC 3629 in Section 1.1.
    
    It is nice that Section 1.1 says "this specification replaces an earlier,
    experimental, approach to the same problem [RFC5336]." It would be even nicer to
    describe the results of the experiment and the resulting protocol differences
    (probably in an Appendix).
    
    Section 3.2 states: "Any domain name to be looked up in the DNS MUST allow for
    [RFC5890] behavior." I don't understand what this means, and I find the use of
    the passive voice confusing here. Does this mean than an SMTP server advertising
    support for the UTF8SMTPbis extension MUST accept DNS domain names that conform
    to RFC 5890? If so, let's say that directly.
    
    Section 3.2 states: "it may choose its own way to deal with this scenario
    according to the provisions of [RFC4409] or its future versions." Do we mean
    "MAY"?
    
    Section 3.5 states: "A UTF8SMTPbis-aware SMTP client MUST only send an
    internationalized message to an SMTP server that supports UTF8SMTPbis." I think
    it would be clearer to say "A UTF8SMTPbis-aware SMTP client MUST NOT send an
    internationalized message to an SMTP server that does not support UTF8SMTPbis."
    
    Section 5 states: "Another security aspect to be considered is related to the
    ability by security team members to quickly understand, read and identify email
    addresses from the logs, when they are tracking an incident." Because reading
    and understanding an email address would require the person to be capable of
    reading the script and understanding the language, I think "identify" is all we
    can hope to promise here (and even that is unlikely in some situations given the
    existence of confusable characters).
  6. Robert Sparks: Discuss [2011-10-18]:
        As Pete notes in the tracker, the document currently has downrefs for 2033 and
    4952bis. To keep these, 3967 currently requires explicitly calling these out as
    part of Last Call, which I don't think has happened. 
        
  7. Robert Sparks: Comment [2011-10-18]:
    When the changes section gets removed, the hint of what happened to the appendix
    in 5336 that updated 4952 goes with it. Would it be easy to add a short note
    somewhere letting the reader know to go look for that in 4952bis?
  8. Sean Turner: Comment [2011-10-16]:
    #1) Do the authors also wish to make RFC 5336 Historic?
    
    #2) Please add a section that lists the difference between RFC 5336 and this
    document.

draft-ietf-eai-rfc5335bis

  1. Jari Arkko: Comment [2011-10-20]:
    Ari Keränen helped me review this, and he said:
    
    Should state in the abstract that this obsoletes and updated various RFCs.
    
    3.  Changes to Message Header Fields
    
        Also note that messages in this format require the use of the
        &UTF8SMTPbis;
    
    The "&UTF8SMTPbis;" looks like a processing error.
    
    3.4.  Effects on Line Length Limits
    
        Section 2.1.1 of [RFC5322] limits lines to 998 characters and
        recommends that the lines be restricted to only 78 characters.  This
        specification changes the former limit to 988 octets.
    
    What is the rationale behind the 988 octet limit?
  2. Ralph Droms: Discuss [2011-10-20]:
        The nit-checker indicates several problems that need to be fixed before
    publication, including some missing and incorrect references (which is why I'm
    recording this issue as a Discuss).
    
    This document includes a normative reference to an Informational draft, which is
    not mentioned in the IESG Writeup and apparently not mentioned in the last call
    text as required by RFC 3967. 
        
  3. Adrian Farrel: Comment [2011-10-18]:
    It would be nice to concentrate section 7 into "changes from RFC 5335" and
    retain it in the document.
  4. Stephen Farrell: Comment [2011-10-16]:
    Almost a total nit but p7 says "If this type is sent to a 7-bit only system, 
    it has to have..." - to what does the "it" refer the emitter of the 
    message or the 7-bit only system? Also - wouldn't saying "<somone>
    MUST do <something>" not be clearer than saying "has to have"
    
  5. Russ Housley: Discuss [2011-10-20]:
        
      The Gen-ART Review by Miguel Garcia on 18-Oct-2011 points out that
      this document includes two normative downrefs.  I do not see either
      of these downrefs in the Last Call for this document:
    
      ** Downref: Normative reference to an Informational draft:
         draft-ietf-eai-frmwrk-4952bis
    
      ** Downref: Normative reference to an Informational RFC: RFC 5598 
        
  6. Russ Housley: Comment [2011-10-20]:
      The title page header indicates that this document obsoletes RFC 5335.
      Please add this fact to the abstract.
    
      The title page header indicates that this document updates RFC 2045.
      Please add this fact to the abstract.
    
      The title page header indicates that this document updates RFC 5322.
      Please add this fact to the abstract.
  7. Sean Turner: Comment [2011-10-16]:
    #1) Do the authors also wish to make RFC 5335 Historic?
    
    #2) Please add a section that lists the difference between RFC 5335 and this
    document.

draft-ietf-dnsext-rfc2672bis-dname

  1. Ron Bonica: Discuss [2011-10-19]:
        The document header and abstract contradict each other. The header says that
    this document obsoletes RFC 2672 and updates RFCs 3363 and 4294. The abstract
    says "This is a revision to the original specification in RFC 2672 as well as
    updating RFC 3363 and RFC 4294 to align with this revision. 
        
  2. Ron Bonica: Comment [2011-10-19]:
    It would be useful if you added an appendix that summarizes the changes to DNAME
    and CNAME between this document and previous documents.
  3. Adrian Farrel: Comment [2011-10-17]:
    I would have liked to see a section that summarised "Changes from
    RFC 2672". (cf. Sean)
    
    ---
    
    It wouldn't hurt to name the registry in Section 7
    
  4. Stephen Farrell: Comment [2011-10-11]:
    - in 2.4 would s/must be involed/MUST be invoked/ be better?
    
    - in 5.3.4.3, last sentence would s/The validator must verify/The
    valiator MUST verify/ be better?
    
  5. Russ Housley: Discuss [2011-10-20]:
        
      The Gen-ART Review by Ben Campbell on 7-Jun-2011 includes:
    
        This draft does not seem to be quite ready for publication, in
        that it professes to obsolete RFC 2672, but does not cover all
        the material from that RFC or explain the absence of the missing
        material.
    
        -- Section 4.2 of RFC 2672, "Processing by Resolvers", is not
          replicated in this draft or it is in a very different form. 
    
        -- Section 5 of RFC 2672, "examples of use" is not replicated in
           this draft. Similar examples are mentioned in the introduction,
           but the detail is removed.
    
      Two revisions of this document have been posted since this review,
      but the issue has not been addressed.  I think it is best resolved
      by the addition of a section that covers the changes since RFC 2672. 
        
  6. Russ Housley: Comment [2011-10-20]:
      The Abstract says: "This is a revision of the original specification
      in RFC 2672, also aligning RFC 3363 and RFC 4294 with this revision."
      The title page header indicates that this document obsoletes RFC 2672,
      and updates RFC 3363 and RFC 4294.  Please explicitly state this
      situation.
  7. Pete Resnick: Comment [2011-10-09]:
    [Probably tilting at a windmill, but...]
    I don't think 2119 language is
    correctly used when talking about whether a server "SHOULD" load a zone. See
    section 2.4 and the last paragraph of section 3.3 and compare section 6 of 2119.
    Not a hill I'm prepared to die on, but I would really like to see this text
    change.
  8. Peter Saint-Andre: Comment [2011-10-19]:
    In Section 1, might the sentence about "punycode alternates for domain spaces"
    benefit by citing RFC 3492? The same is true for Section 5.1.
    
    Section 2.1 has "class-sensitive" -- is "case-sensitive" meant here?
    
    Section 2.1 has "must be sent in uncompressed form" -- is MUST meant here?
    
    Section 2.4 notes that "A server SHOULD refuse to load a zone that violates
    these rules." Are there particular circumstances under which it is acceptable to
    violate this SHOULD?
    
    The "Requirements Language" boilerplate text after the Abstract does not include
    "NOT RECOMMENDED", but Section 4 includes that term; please add it to the
    boilerplate (this will be accepted by the RFC Editor).
  9. Sean Turner: Comment [2011-10-13]:
    #1) Many times when a document obsoletes another there's a section in the new
    document that summarizes what's changed.  Such a section would be nice to have
    in s1.

draft-ietf-nfsv4-federated-fs-dns-srv-namespace

  1. Jari Arkko: Discuss [2011-10-20]:
        I do not understand why the document prohibits the use of DNS-SD to discover
    NFSv4 services. If I don't have a DNS server in my home network and I want to
    access information from a NFSv4 capable server, it should work, no? 
        
  2. Jari Arkko: Comment [2011-10-20]:
    I'm not sure why the mount point conventions are needed.
  3. Ralph Droms: Discuss [2011-10-18]:
        This document proposes the use of SRV records for mapping of names
    of the form <domainroot-service>.<domain> to a mounted filesystem in
    an NFS client namespace.  My review is based on two reviews from the
    DNS Directorate and my own reading of the document.
    
    1. The service name specified for the "domainroot" function are a two
    label name "_nfs._domainroot." and a three label name
    "_nfs._write._domainroot."  As I understand the use of these two
    service names, they identify two unique, related services for NFS
    clients.  Based on the use of these service names described in this
    document, there is no need for multi-label service names, and the
    specification could be simplified by using, e.g., "_nfs-ro." and
    "_nfs-rw." for the service names.
    
    2. If there is some expectation for future service sub-types for
    NFS-related service names, it would be appropriate to define a "_nfs."
    service with, e.g., "_domainroot-ro." and "_domainroot-rw." subtypes.
    In this case, the names for read-only and read-write domain roots
    would be:
    
    _domainroot-ro._nfs._tcp.example.com
    _domainroot-rw._nfs._tcp.example.com
    
    3. In section 4:
    
       "This DNS SRV record evaluation, could in principle, be done either
       in the NFSv4 client or in the NFSv4 server....." 
    
    Only the NFSv4 client can perform the DNS resolution as it
    may have a different resolution context than the server in split DNS
    scenarios. 
        
  4. Ralph Droms: Comment [2011-10-18]:
    1. To make sure I'm understanding the use of this SRV RR, is it
    intended to provide information about the root of an NFS file system
    published as the "uniform file name space" for an organization?
    Although the target field of the RR could point to any NFSv4 file
    server, by convention as defined in this document, the target is the
    root of this "uniform file name space."
    
    2. Section 4.2 Paragraph 5:
    
    One of the main points of SRV records is to allow the usage of
    different ports on servers for provision of service I would like to
    see the example here use other port than 2049 in at least one example.
    Or does the NFSv4 specification say "YOU MUST ONLY USE PORT 2049"?
    
    3. In order to facilitate the provision of both R/O and R/W copies of
    the same mount point, in theory the Priority field can be used.
    Lowest priority field is RO, RW are higher priority.  This document
    would give advice on Priority ranges to use for different kinds of
    systems.
    
    Example:
      0.10 Read-only
      100..110  Read/Write copies
      10000..10010 Fresh Read/Write copies
    
    Thus only clients that know what kind of copy they need will use the
    appropriate subset of SRV records when selecting a server.  In this
    case different sever ports would provide the different access, not
    different external names.
    
    Example:
        _nfs._tcp SRV 0 1 45503    BigServer.example.net.
        _nfs._tcp SRV 0 2 2049     SmallServer.example.net.
        _nfs._tcp SRV 101 1 49934  BigServer.example.net.
        _nfs._tcp SRV 10010 3 2049 Backend.example.net.
    
    Due to the way how records are selected (if RFC2782 selection
    algorithm is followed) the probability of using high priority servers
    by read-only clients is quite low.
    
    4. It might not be a bad idea if the draft analyzed the likely effects
    of split-brain, DNS64, and so on, but I'm not sure it's necessary.
    
    5. Assuming IANA is being asked to register these service names in the
    Service Name and Transport Protocol Port Number Registry [RFC6335], it
    would be helpful to identify the registry explicitly and cite RFC 6335
    in section 7.
    
    Comments 6, 7 and 8 are related to NFS rather than the SRV record
    defined in this document.
    
    6. The convention of using /domainroot-example.net and
    /.domainroot-example.net for the read-only and read-write versions of
    the example.net file system is not intuitive to me.  Why use the "."
    prefix rather than, say, /domainroot-ro_example.net and
    /domainroot-rw_example.net?
    
    7. Similarly, why use the "." convention for mounting the filesystem
    in the client?
    
    8. Are the details of the integration process sketched in section 5
    written down in more detail somewhere else?  In my opinion, I'm not
    sure section 5 will ensure a uniform use of the SRV record across all
    clients.
    
  5. Adrian Farrel: Comment [2011-10-04]:
       The NFS version 4 protocol provides a natural way for a collection of
       NFS file servers to collaborate in providing an organization-wide
       file name space.
    
    I love "natural." Is that just using herbal essence, or do you also use
    crystals?
    
    ---
    
    Section 3 might be a bit more definitive. No need to "propose" things in
    a published RFC.
  6. Russ Housley: Discuss [2011-09-30]:
        
      The Gen-ART Review by David Black on 26-Sept-2011 raises some
      concerns that deserve a response.  Please find the review at
      http://www.ietf.org/mail-archive/web/gen-art/current/msg06749.html. 
        
  7. Pete Resnick: Comment [2011-10-05]:
    I agree with the concerns regarding the SRV record and the mount points.
  8. Peter Saint-Andre: Discuss [2011-10-03]:
        I concur with the DISCUSS raised by Russ Housley in reference to the Gen-ART
    review: as far as I can see, a Service name of "_nfs4._domainroot" is not
    consistent with RFC 2782. If indeed the WG has formulated a solution to that
    problem ("in the form of a unitary single-level service name"), and if the WG
    has consensus on that proposed solution, then the I-D should be revised to
    incorporate that solution. Until that is done (or some other solution is found),
    I do not think it is appropriate to advance this specification to Proposed
    Standard. 
        
  9. Robert Sparks: Discuss [2011-10-04]:
        I expect to clear or revise this discuss quickly based on discussion:
    
    It's unusual to standardize a directory name in a host's filesystem namespace
    (see section 4.1). Has the IETF done this before? Is it the right organization
    to establish this kind of convention? 
        
  10. Robert Sparks: Comment [2011-10-04]:
    I support Peter's discuss.
  11. Sean Turner: Comment [2011-10-04]:
    s4.2: r/recommended/RECOMMENDED in the following:
    
       As for the other attributes in fs_locations_info, the recommended
       approach is for a client to make its first possible contact with any
       ...
    

draft-ietf-grow-no-more-unallocated-slash8s

  1. Wesley Eddy: Comment [2011-10-18]:
    Support Stephen's DISCUSS and agree with Adrian's COMMENT.
  2. Adrian Farrel: Comment [2011-10-17]:
    If there are no more unallocated /8s, I cannot understand how a filter for
    unallocated /8s would be in any way a problem.
    
    The second paragraph of the Abstract and the Introduction is, therefore,
    confusing.
    
    I think this could be clarified in terms of the language in the first paragraph
    about "unallocated address space." Or you could use the language of section 3.2.
  3. Stephen Farrell: Discuss [2011-10-17]:
        discuss discuss
    
    Should this wait on, and reference, the potential /10
    allocation of draft-weil-shared-transition-space-request
    assuming that that /10 is approved? 
        
  4. Pete Resnick: Comment [2011-10-18]:
    Windmill tilt: I see no reason that this can't be a Proposed Standard in that it
    is giving implementation advice.

draft-ietf-sidr-ghostbusters

  1. Jari Arkko: Comment [2011-10-20]:
    This document could only have been written by Randy :-)
  2. Adrian Farrel: Comment [2011-10-16]:
    As you will be aware (having read RFC 5513) it is hard to find a previously
    unused three letter combination. I don't think there are any issues with using
    the .gbr filename extension, but be aware that it is also used by gimp graphics
    package.
  3. Stephen Farrell: Comment [2011-10-11]:
    1) I originally had a discuss saying:
    
       I don't see how I'd actually find the ghostbuster record say 
       starting from a CRL or cert or signed object that I think may be
       (about to be) problematic.  That's probably really clear to rpki
       folks but from just reading this I don't get it, and given the
       purpose of the record it might be worth saying something in the
       document. I'm sure I'll clear once someone provides the (probably
       obvious;-) answer.
    
    That was answered quickly by Randy saying:
    
    > from the object, go up to the CA cert, which may be the object itself,
    > of course.  that cert has an SIA to the publication point where all
    > subsidiary objects (until you hit a down-chain CA cert's signed objects)
    > are published.  the publication point will contain zero or more gbrs.
    
    I reckon it'd be good to say something like that in the doc as well.
    
    2) Is it considered acceptable to not put a person's name in the FN
    field of the record but rather a role, e.g. "shit/fan separator" or
    the polite equivalent? If that's considered ok, maybe pointing it
    out would be good. If not, then perhaps emphasise that the FN must
    be the name of a real person but then I wonder how this is
    maintained when the current shit/fan separator goes on vacation or
    gets fired.
    
  4. Russ Housley: Comment [2011-10-17]:
      Please consider the comments from the Gen-ART Review from
      Miguel Garcia on 19-Sep-2011.  The review can be found here:
      http://www.ietf.org/mail-archive/web/gen-art/current/msg06741.html
  5. Pete Resnick: Comment [2011-10-09]:
    I was left a bit confused about what precisely is *the* Ghostbusters Record. I
    got lost as to what was the record, and what was the payload of the record. It
    would have helped me if in addition to, "The Ghostbusters Record conforms to the
    syntax defined in [I-D.ietf-sidr-signed-object]", you would have added the
    sentence "The payload of this signed object is a severely profiled vcard", and
    maybe having something in the "Additional Information" in the media type
    registration that it is the SIDR signed-object, not the vcard data, that is
    being defined as the media type. Maybe folks who work in this space would not
    have gotten confused, but as random MIME schmo, it took me going back and forth
    a few times to be clear on what was what.

draft-ietf-appsawg-rfc3462bis

  1. Ron Bonica: Comment [2011-10-19]:
    Concur with Russ' discuss.
  2. Adrian Farrel: Comment [2011-10-18]:
    Cleared my Discuss after discussion
  3. Russ Housley: Discuss [2011-10-17]:
        
      This should be going to Internet Standard under the new process. 
        
  4. Robert Sparks: Discuss [2011-10-18]:
        I encourage advancing this under RFC6410.
    
    That change to the process no longer _requires_ an implementation report, but
    since this was originally intended for publication as Draft standard, I assume
    one's been put together? I'm not finding it at <http://www.ietf.org/iesg
    /implementation-report.html> and it would be a shame to lose it if it's already
    done. 
        
  5. Sean Turner: Discuss [2011-10-18]:
        Updated based on -02.
    
    <process weenie>
    
    #1) The authors are contacting the authors of 3462 - so I this is really just a
    placeholder discuss until the 3462 authors says yes/no and the boilerplate gets
    left alone/changed.
    
    I'm hoping the answer to this is yes, but I had to ask because I didn't see it
    in the proto write-up:
    
    This document doesn't have a pre-5378 disclaimer and the author set is not the
    same as RFC 3462.  Did Gregory grant the rights to the IETF Trust to
    allow the document to be published without the pre-5378 disclaimer?
    
    #2) addressed in -02
    
    #3) cleared
    
    </process weenie>
     
        
  6. Sean Turner: Comment [2011-10-18]:
    #1) Do the authors also wish to make RFC 3462 and or 1892 Historic?
    
    #2) I'll leave it to Pete/Barry if the additions as a result of discuss #2
    require coordination with ietf-types@ietf.org

draft-ietf-ccamp-attribute-bnf

  1. Russ Housley: Comment [2011-10-20]:
      I want to build on two comments that were originally offered in the
      Gen-ART Review by Vijay Gurbani on 17-Oct-2011.
    
      Section 2 includes an group of indented paragraphs, and all but one of
      those paragraphs contains an RFC 2119 key word.  Please consider making
      the "must" in that paragraph into "MUST".
    
      Section 3 includes an group of indented paragraphs, and all but one of
      those paragraphs contains an RFC 2119 key word.  Please consider making
      the "must" in that paragraph into "MUST".

draft-ietf-mpls-tp-li-lb

  1. Ron Bonica: Comment [2011-10-20]:
    Please run the spell checker over this document.
  2. Stephen Farrell: Comment [2011-10-17]:
    - It seems that the LI message allows setting a timer so that
    repeat LI messages only need to be sent every 255 seconds, and one
    of those every ~15 minutes (255*3.5) would keep a locked section
    locked.  Would it be worth nothing this potential DoS in the
    security considerations, since that's quite a good return for the
    putative attacker in terms of bits sent by the attacker vs. bits
    not sent due to the DoS?
    
    - NMS is used but not expanded/defined
    - s/despatch/dispatch/?
    - s/must e/must be/
    - s/either end/both ends/ would be better in 6.2, 1st para
    
  3. Sean Turner: Comment [2011-10-17]:
    s1.1: Is it update or replace s7.1.1?  I guess it really doesn't matter, but if
    the intent is really to completely replace then maybe it'd be clearer to just
    say that.  Also, s6.2 of this draft discusses unlocking and s7.1.2 discussed
    unlocking so shouldn't s1.1 of this draft also point out that 7.1.2 is also
    updated/replaced?
    
    s2.2: RFC 6371 uses LKI for Lock Instruction instead of LI.  Are there other
    MPLS RFCs/I-Ds that use LKI instead of LI?  Just trying to make sure they're all
    lined up nicely.
    
    s2.2: add: NMS     Network Management System
    
    s4.1: r/This possible for/This is possible for ?
    
    s5.2: Any reason to not start at 0?  Seems like you're burning a number.
    
    s7: Well I'm not so sure it's a security issue, but is there a concern about
    sending real traffic during a loopback?  In other words should you always send
    some dummy traffic?

draft-gundavelli-v6ops-pmipv6-address-reservations

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

draft-melnikov-mmhs-header-fields

  1. Jari Arkko: Comment [2011-10-20]:
    I agree with the issues raised on the normative reference. These should be
    available. Also, the document says:
    
    > Note: There is no guarantee that the exempted
    > addresses will not receive the message as the result of redirection,
    > Distribution List (DL) expansion, etc.
    
    This is pretty weak language for a military spec. But it is not my army, so....
    
  2. Adrian Farrel: Comment [2011-10-17]:
    Section 1
    
       This document enables the provision of most of the elements of
       service defined in STANAG 4406 [STANAG-4406] for Internet Email.
    
    It would be nice to have a forward pointer to section 5.
    
    ---
    
    Section 3
    
       Any header field specified in this document MUST NOT appear more than
       once in message headers.
    
    It would be usual to state what a receiver does if this rule is broken,
    even if the statement is simply a reference to normal behaviour in a
    specific RFC.
    
    ---
    
    The anchors seem to be broken.
      Specification document(s): [[anchor4: this document]]
      Specification document(s): [[anchor6: this document]]
      Specification document(s): [[anchor8: this document]]
    etc.
    
    ---
    
    Section 3.2
    
       This header field SHOULD always be present in an email message which
       complies with this specification.
    
    Since we are talking about "compliance" you probably need to set out the
    conditions under which the field MAY be absent.
    
    ---
    
    Section 3.6
    
       If this header field is
       absent the message will be considered received without the Codress
       format.
    
    s/will/MUST/ ?
    
    Actually, I find a number of uses of "will", "should" etc. throughout
    the document and I am unclear when you mean to use 2119 language and
    when not.
    
    ---
    
    Section 3.7
    
       Note: trailing and leading spaces in an originator reference are not
       allowed.  Any leading or trailing spaces would be stripped.
    
    "would be" under what circumstances? :-)
    I think you need to replace "are not allowed" and "would be" with 
    RFC 2119 language.
    
    ---
    
    Section 3.8
    
       The MMHS Primary Precedence Element of Service indicates the relative
       order in which Military Messages are to be handled for primary
       (action) recipients, i.e. a Military Message with higher MMHS-
       Primary-Precedence header field value should be handled before a
       Military Message with a lower MMHS-Primary-Precedence header field
       value.
    
    s/should/SHOULD/ ?
    
    Ditto section 3.9
    
    ---
    
    Section 3.8
    
       Example 1:
       MMHS-Primary-Precedence: 0 (Deferred)
    
    The previous text said:
    
       The header field value is an integer, or one of the 6 predefined
       case-insensitive labels: "deferred" (same as "0"), "routine" (same as
       "1"), "priority" (same as "2"), "immediate" (same as "3"), "flash"
       (same as "4"), or "override" (same as "5").
    
    So the example appears not to be conformant.
    
    Ditto section 3.9
    
       Example 1:
       MMHS-Copy-Precedence: 4 (flash)
    
    This is explained at the foot of 3.10 by...
    
       Note that some of the examples above demonstrate use of optional
       comments.  See Section 4 for the exact syntax of this header field.
    
    Which is a little late to be convenient.
    
    ---
    
    Section 3.14
    
       The originator Plain Language Address Designators (PLAD) header
       field, by its presence indicates the plain language address
       associated with an originator for cross reference purposes.
    
    Please explain why the reference is cross. What upset it? Does it 
    always get angry when its hyphen is left out?
    
    ---
    
    Section 8
    
    For clarity, I always think it is nice to give detailed and specific
    instructions to IANA. OTOH they are clever and will work it out.
    
    ---
    
    Section 9.
    
    Given that the Security ADs are all over this document, I will not
    comment more than saying that the Gateway function described in this
    document seems to raise interesting security concerns in that it 
    provides a mechanism to transfer a security breach in one mail system
    into the other mail system. Thus, the combination is only as strong
    as its weakest component.
  3. Stephen Farrell: Discuss [2011-10-13]:
        I'm not sure I agree there are no new security considerations here
    given that these header fields are not protected by S/MIME but are
    (I think, maybe I remember wrong) signed in X.400 MMHS or 
    ACP <foo>.  Am I right there?
    
    If so with a message like this I could for example delete the 
    MMHS-Exempted-Address header field for example and bad stuff 
    might happen. In that case, you probably need to include some
    analysis of the potential bad things and might want to RECOMMEND
    signing with DKIM perhaps.
    
    If I'm wrong and the equivalent 4406 extensions cannot be
    signed then I agree there's nothing much new here and will 
    clear.
    
        
  4. Stephen Farrell: Comment [2011-10-13]:
    - It seems a bit odd that this is informational - I'd have
    expected the consumers of this to require a standards track
    document for it to be really useful to them. But I guess
    the authors know better.
    
    - IPMS is used without expansion
    
    - The ACP 127 reference would be better provided where its
    first mentioned.
    
    - What is "the Extensions heading field" in 3.1 and why is the
    header field called "this extension" here? Is that text leakage from
    4406?
    
    - in 3.2 would s/was submitted/was initially submitted/ be more
    correct? 
    
    - 3.2 says this one SHOULD be included, might be useful to say
    these are all OPTIONAL unless otherwise stated?
    
    - For values like the SIC codes, and others, can you give a 
    reference to relevant registries? That should help someone
    trying to write code from this.
    
    - 3.4 says this is "human readable" but the example "ZNY; RRRR"
    doesn't strike me as Shakespear-like:-) And is there an (open)
    registry of codes for this?
    
    - Should you have a reference to how to encode ACP127 in a MIME
    body in 3.6?
    
    - In 3.7 what does "would be stripped" mean? Is that really a 
    MUST and if so, for whom?
    
    - In 3.8 s/shall ensure/MUST ensure/ ?
    
    - 3.10 calls this one a "heading extension" which seems wrong
    
    - 3.10 s/may includes/may include/
    
    - I assume there are no I18N problems with the values that are
    allowed in all of these fields - is that right?
    
    - I think you could mention that DKIM could be used to sign these
    header fields at least.
    
  5. Russ Housley: Comment [2011-10-20]:
      I think the tone of the Abstract sends the wrong message to the
      reader.  I suggest the following re-write:
    
      OLD:
    
       A Miltary Message Handling System (MMHS) processes formal messages
       ensuring release, distribution, security, and timely delivery across
       national and international strategic and tactical networks.  The MMHS
       Elements of Service are defined as a set of extensions to the ITU-T
       X.400 (1992) international standards and are specified in STANAG 4406
       Edition 2.  This document describes a method for enabling those MMHS
       Elements of Service that are defined as Heading Extension to be
       encoded as RFC 5322 (Internet Email) message header fields.  These
       header field definitions support the provision of a STANAG 4406 MMHS
       over Internet Email, and also provides for a STANAG 4406 / Internet
       Email Gateway supporting message conversion compliant to this
       specification.
    
      NEW:
    
       A Miltary Message Handling System (MMHS) processes formal messages
       ensuring release, distribution, security, and timely delivery across
       national and international strategic and tactical networks.  The MMHS
       Elements of Service are defined as a set of extensions to the ITU-T
       X.400 (1992) international standards and are specified in STANAG 4406
       Edition 2.  This document specifies message header fields and
       associated processing for RFC 5322 (Internet Email) to provide a
       comparable messaging service.  In addition, this document provides
       for a STANAG 4406 / Internet Email Gateway that supports message
       conversion.
  6. Peter Saint-Andre: Comment [2011-10-19]:
    Several reviewers have provided very detailed feedback, so I am restricting my
    comments to a few small points in the text.
    
    1. Is MMHS / STANAG 4406 only for communication among NATO member countries? If
    so, the text in the Abstract and the Introduction over-promises.
    
    2. Section 1 states: 'The RFC 5322 header fields defined are prefixed with the
    string "MMHS-" to distinguish them from any other header fields.' Can the
    "MMHS-" prefix be used in any other header fields, or is the intent that it is
    being locked down by this specification? For the record, I think the latter
    approach would be a bad idea and not enforceable by IANA.
    
    3. In Section 3.8, "MMHS-Primary-Precedence: 7" appears to use a disallowed
    label.
    
    4. Section 3.10 has a typo: "MMHS-Message-Type: 2 (projet)"
    
    5. Given the definition of "integer" in Section 4, +0 and -0 seem to be allowed.
    Is that correct?
  7. Sean Turner: Discuss [2011-10-20]:
        This is an updated discuss.
    
    Despite the length of these I believe a draft that translates MM-header fields
    to RFC5322-header fields is publishable.
    
    #1) STANAG 4006 is listed as a normative reference.  It's not available on the
    NATO site (http://www.nato.int/cps/en/SID-
    8BF0F167-D3248540/natolive/stanag.htm).  It was on Graeme's company site, but
    the link doesn't seem to work.  I couldn't find it on other publicly available
    sites (maybe I didn't look hard enough).  I have two questions that I think go
    to the need for normative references to be publicly available:
    
    a) Is this document actually publicly/widely available?  Assuming it can't be
    had on the Internet, I know that you can get hard copies IF you contact your
    NATO-member national body (e.g., UK MoD, USA DoD) (kind of like asking a
    publisher to give you a copy of a book/article they published - but I don't
    think these publishers will charge you - not sure about this though).  However,
    how is somebody who lives in a country that is not part of NATO going to get a
    hard copy?  Will NATO respond to queries for STANAG's from people who have non-
    NATO nationalities or who don't live in NATO member states?  I've got not idea -
    just asking.
    
    b) Is the version on Graeme's company site official and final?  If not shouldn't
    "draft" appear in the reference?
    
    If Graeme's site doesn't have active links and NATO won't give it to folks who
    live in non-NATO countries - is STANAG 4406 really available?
    
    If STANAG 4406 doesn't seem like a viable reference you could switch the whole
    thing around to refer to ACP 123 - it's available online.
    
    #2) I think I might be reading way more in to this than I should, but I think
    you can't say that by translating these services you're enabling MMHS services
    in Internet mail.  To me that sounds like advertising and I think if that
    statement was to be made somebody who works for NATO (or maybe a NATO-member
    nation) would would need to say it.  It's like when a draft author claims their
    draft is Suite B compliant - somebody from the NSA would have to say that not
    the author (unless they worked at NSA).  I think if you're clinical about it -
    i.e., this document translates from this to this - then you're okay.  What
    follows are the tweak I think you need to make.  My intent with the suggested
    changes is to ensure the information necessary for implementers to implement is
    still there - and I hope I've done that.
    
    title:
     OLD:
      Registration of Military Message Handling System (MMHS) header fields
                            for use in Internet Mail
     NEW:
      Registration of SMTP header fields for Military Messages
    
    abstract:
     OLD:
       The MMHS
       Elements of Service are defined as a set of extensions to the ITU-T
       X.400 (1992) international standards and are specified in STANAG 4406
       Edition 2.   This document describes a method for enabling those MMHS
       Elements of Service that are defined as Heading Extension to be
       encoded as RFC 5322 (Internet Email) message header fields.  These
       header field definitions support the provision of a STANAG 4406 MMHS
       over Internet Email, and also provides for a STANAG 4406 / Internet
       Email Gateway supporting message conversion compliant to this
       specification.
    
     NEW:
       The MMHS
       Elements of Service are realized as a set of extensions to the ITU-T
       X.400 (1992) international standards, which are referred to as Military
       Messaging (MM) header fields, and are specified in STANAG 4406
       Edition 2.   This document describes a method for translating Military
       Message (MM) header fields, which are defined as X.400 Heading
       Extension and that realize the MMHS elements of service,
       to RFC 5322 (Internet Email) message header fields.  These
       header field definitions provide for a STANAG 4406 / Internet
       Email Gateway.
    
    s1:
     OLD:
       This document enables the provision of most of the elements of
       service defined in STANAG 4406 [STANAG-4406] for Internet Email.
    
     NEW:
       This document supports translating most of the MM-message header fields
       defined in STANAG 4406 [STANAG-4406] to Internet message header fields.
    
    s3.3:
     OLD:
       [STANAG-4406] specifies two optional components of the Distribution
       Code Element of Service.
    
     NEW:
       [STANAG-4406] specifies two optional components of the Distribution
       Codes header.
    
    s3.8 and s3.9: 
     OLD:
       The MMHS Primary/Copy Precedence Element of Service indicates the
       relative order in order in which Military Messages ...
    
     NEW:
       The primary/copy precedence header indicates the relative order
       in which messages ...
    
    s3.11 and 3.12: *=primary or copy (note there's a related comment about the
    second part, but I thought I'd give it all to you here):
     OLD:
       The other *
    recipients indicator header field, by its presence
       indicates the names of *
    recipients that are intended to
       receive or have received the message via
    means other than MMHS.  The
       absence of this element does not guarantee that
    all recipients are
       within the MMHS.
    
       This MMHS Element of Service enables an MMHS recipient to determine
       all recipients of a Military Message.  There are several reasons as
       to why a recipient of a Military Message may be identified by this
       header:
    
       1.  The recipient is not part of the MMHS
    
       2.  The path to the recipient through the MMHS may not be secure,
           therefore, the originator has used alternative mechanisms to
           distribute the Military Message
    
       3.  The recipient was already in receipt of the Military Message
           prior to it being inserted into the MMHS
    
     NEW:
      The other * recipients indicator header field, by its presence
      indicates the names of * recipients that are intended to
      receive or have received the message via other means.  It enables
      a recipient to determine all action/information recipients of a
      message.  This header field is derived from the MM-header Other
      Recipient Info.
    
    s3.13: (actually the part I deleted isn't in 4406)
     OLD:
       This header field is used only to support interoperability with ACP
       127 systems, it should be treated as opaque by a pure MMHS system.
     NEW:
       This header field is used only to support interoperability with ACP
       127 systems.
    
    s3.14
     OLD:
       This MMHS header field and the Extended Authorisation Info header ...
     NEW:
       This header field and the Extended Authorisation Info header ...
    
    s5:
     OLD:
       The service specified in this document is a subset of the
       functionality set out in Annex A1 "Military Heading Extensions" of
       [STANAG-4406].
     NEW:
       The headers specified in this document are a subset of the
       headers set out in Annex A1 "Military Heading Extensions" of
       [STANAG-4406].
    
    s7:
     OLD:
       The header fields defined in this specification include fields to
       carry ACP 127 specific elements of service [ACP127]. 
     NEW:
       The header fields defined in this specification include fields to
       carry ACP 127 specific values [ACP127]. 
    
    #3) I pulled out my handy-dandy copy of ACP 123 and noted that the value range
    for precedence (primary and copy) as well as message type are entirely reserved
    for NATO and national use.  How will additions be handled?  Is the IESG or IANA
    going to tell non-NATO national entities they can't define values in that space?
    For example, New Zealand comes along and wants to add "faster than sheep" as a
    precedence as 6 - what happens?
    
    #4) cleared
    
    #5) s5 contains the following text:
    
      A few capabilities have been left out which would
      have significantly increased the complexity of this specification,
      and do not appear to be of significant benefit.
    
    I'm not entirely sure you can say the last bit without an additional qualifier
    like: (in the eyes of the authors who don't speak for NATO or any nation that's
    a part of NATO).  Unless of course you are?  Maybe you can just delete the last
    bit.
    
    There's also the second sentences for distribution codes and pilot forwarding
    info:
    
       Distribution
       extensions are not widely used, and encoding ANY DEFINED BY in this
       specification would be difficult.
    
       This complex
       extension is only for ACP 127 transition, and is not widely used.
    
    You know this for absolutely sure?  This sounds like you're speaking
    authoritatively for NATO and I'm not sure you can.  You could just list the ones
    you didn't map and leave it at that. 
        
  8. Sean Turner: Comment [2011-10-20]:
    #1) a/s1: Expand STANAG: Standardization Agreement (STANAG)
    
    #2) s1: Pretty sure STANAG 4406 never uses the term "military mail". Suggest
    "military messaging (MM)" instead.
    
    #3) s1: (This is kind of linked to discuss #2.) Contains the following:
    
       This document enables the provision of most of the elements of
       service defined in STANAG 4406 [STANAG-4406] for Internet Email.
    
    Something wrong - maybe provisioning?  Maybe:
    
       This document supports translating most of the MM-message header fields
       defined in STANAG 4406 [STANAG-4406] to Internet message header fields?
    
    #4) s1: expand IPMS
    
    #5) s1: If there are other aims where are they listed?  Maybe just remove the
    word "primary" from the 1st sentence in the 3rd para.
    
    #6) s2: Contains the following:
    
       The formal syntax use the Augmented Backus-Naur Form (ABNF) [RFC5234]
       notation including the core rules defined in Appendix B of RFC 5234
       [RFC5234].
    
    Maybe r/use/uses
    
    #7) s3.*: I know a lot of this was copied from 4406 and you'll want to maintain
    alignment, but maybe these could be fixed:
    
    a) Contains:
    
      header field, by its presence indicates ...
    
    I think maybe there should be a comma:
    
      header field, by its presence, indicates ...
    
    b) s3.1, s3.4, 3.5, s3.6, s3.7, s3.8, s3.13, s3.14: Contains phrases like:
    
      If this header field is absent, then then the message will
      be considered to ... not have, to have no ... 
    
    Do you really need to say if the extension isn't there then the message should
    be like the extension isn't there?  I know that some specs are written for
    vendors who might do really silly things, but these sentences seem completely
    unnecessary.
    
    #8) s3.5: Good that you mention ACP 123 ;)  ACP 123 indicates that message
    instructions:
    
      They are used for informational purposes at the end points.
    
    Might be worth adding this so that implementers know they're not supposed to do
    anything with them.
    
    #9) s3.5: Should you also add the message instructions are sometimes called
    "remarks"?
    
    #10) s3.7: I'm not sure you got the example right (though I could be wrong).  I
    don't think UNCLAS should be there.  That's part of the rest of the format
    line/message, but it's not part of the reference.
    
    #11) s3.8 and s3.9: r/should/SHOULD in the following?:
    
       i.e. a Military Message with higher MMHS-
       *-Precedence header field value should be handled before a
       Military Message with a lower MMHS-*-Precedence header field
       value.
    
    #12) s3.8 and s3.9: r/shall/SHALL in the following?:
    
       The message originating domain shall ensure that ...
    
    Kind of like the should for the extended authorization information?
    
    #13) s3.8 and 3.9: Why add the unnecessary complexity of allowing integers or
    the string?  Why not just pick one?  4406 is an integer ;)
    
    #14) (final outcome in discuss #2) s3.11 and s3.12: Contains the following
    phrase:
    
       This MMHS Element of Service enables an MMHS recipient to determine
       all recipients of a Military Message.
    
    Two things:
    
    1) There's no MMHS EoS called Other Recipient Info To/CC.  Maybe something like:
    
      This header field is derived from the MM-header Other Recipient Info.
      It
    enables an MMHS recipient to determine all recipients of a Military Message.
    
    2) These extensions combined would allow you to determine the other recipients,
    but one alone can't.  So I think you have to say something like (action/info
    depends on whether it's primary/copy):
    
      The other * recipients indicator header field, by its presence
      indicates the names of * recipients that are intended to
      receive or have received the message via other means.  It enables
      a recipient to determine all action/information recipients of a
      message.  This header field is derived from the MM-header Other
      Recipient Info.
    
    #15) s3.13: I know a lot of these got copied, but this one doesn't make sense:
    
       The ACP127 message identifier header field, by its presence indicates
       an ACP 127 message identifier [ACP127] which originated from an ACP
       127 domain.  If this extension is absent, then the message did not
       encounter an ACP 127 domain.
    
    This is a little confusing to me.  Maybe:
    
       The ACP127 message identifier header field, by its presence, indicates
       an ACP 127 message identifier [ACP127] for a message that originated
       from an ACP 127 domain.  If this extension is absent, then the message
       did not encounter in an ACP 127 domain.
    
    #16) s3.14: I searched ACP 127 and couldn't find the acronyms for DERI, SSN, or
    JFT.  Did these come from someplace else?
    
    #17) s3.14: The last bit isn't in STANAG 4406 maybe delete it:
     OLD:
       This header field is used only to support interoperability with ACP
       127 systems, it should be treated as opaque by a pure MMHS system.
     NEW:
       This header field is used only to support interoperability with ACP
       127 systems.
    
    or should this be added to every other paragraph that says a header is only used
    for interop?
    
    #18) s4: Contains date-time.  Should you also have a pointer to where it is
    defined like address-list?
    
    #19) s4: The following appears in the ABNF, but I'm not sure it's used:
    
      DesignatorType = "primary" / "copy"
    
    #20) s5: What no discussing about the clear EoS? :)
    
    #21) s5: Contains the following:
    
       This
       extension is deprecated in favour of Annex A, 
    
    Annex A of ?  I assume STANAG 4406, but I'm not entirely sure.
    
    #22) s6: r/should/SHOULD in the following (or is it in 2156?):
    
       OR Names should be
       mapped with Internet Email addresses according to [RFC2156].
    
    #23) s6: r/and/or - would ever sign the message both ways?
    
       The X.400 message MAY be signed according to
       STANAG 4406 Annex B and Annex G.
    
    #24) s9: I tend to agree with Stephen and his discuss about the security
    considerations.
    
    #24) s10.1 and s10.2: Should probably add (G) to ACP127 reference and (B) for
    the version of ACP123 to match what is in the main body.  Likewise the version
    for ACPs 121 and 131 should be added.

draft-jdfalk-maawg-cfblbcp

  1. Jari Arkko: Discuss [2011-10-20]:
        It is a good idea to publish this, thank you for bringing it to an internet
    draft form and the IETF.
    
    However, I think the copyright disclaimer statements are currently in an
    unacceptable form. Is this a mistake, or were these settings deliberate? I think
    we need to discuss this. The document is also internally inconsistent:
    
       While not originally written as an
       Internet Draft, it has been contributed to the IETF standards
       repository in order to make it easier to incorporate this material
       into IETF work.
    
    ....
    
       This document may not be modified,
       and derivative works of it may not be created, and it may not be
       published except as an Internet-Draft.
    
    and yet it is brought to the IETF to incorporate material into IETF work, and to
    publish as an RFC! 
        
  2. Wesley Eddy: Comment [2011-10-18]:
    There are some characters misaligned in Figure 1 that should be fixed.
    
    It's probably not right to say "IETF standards repository" in the abstract; I
    think you really just mean "the RFC Series" or something like that.
  3. Stephen Farrell: Discuss [2011-10-16]:
        
    It seems wrong to recommend ways to figure out the actual
    recipient email address from which the complaint originates, when
    that has been (perhaps badly) redacted by the feedback provider.
    I doubt such text would be accepted as-is in an IETF WG 
    document.
    
    Shouldn't the text on p25 ("It can be very difficult to extract...")
    down to "...and trending analysis).") that hints at how to do that
    also at least say that doing so is acting contrary to the wishes of 
    such a feedback provider and perhaps the end user that originated 
    the complaint? Or, perhaps you should give some more effective 
    advice to the privacy sensitive end-user or feedback provider? 
    (Which may practically amount to "don't *ever* send feedback";-)
    
    Note: I'm not asking that the mail industry reform itself and I'm not 
    sure how effective it may be to put a discuss on a document like 
    this, but I'd be much happier if this could be fixed somewhat. 
    
    So I guess the first part of my discuss to think about is:
    
    Is there some way to fix this for the IETF version of the document? 
        
  4. Stephen Farrell: Comment [2011-10-16]:
    There are quite a few comments here. Given the provenance 
    of this document, I'm pretty much fine if they're entirely ignored 
    and just offer than as a potential ways to improve the text if 
    doing so is possible at this point in time.
    
    - It seems a bit odd that this I-D is justified as being a way to
    allow MAAWG work items to be more easily referenced, but yet, this
    document refers to other MAAWG without apparent difficulty. (Refs,
    [2,5]) I've no objection to this, but it does make me curious.
    
    - secdir review comment: The security considerations consist of a
    single line that refers readers to 3 other sections of the draft,
    none of which it appears to me deal with security. I would suggest a
    rewording of this to make the section broadly address the security
    implications of implementing, joining, or contributing to a
    "complaint feedback loop". Maybe also have a little something about
    countermeasures or dealing with spammers trying to game the system.
    
    - Definition of FBL - why bother? if you leave it in then maybe s/in
    this document/in the rest of this document/ because the current
    statement is false and self-contradictory.
    
    - Just to note that the term "loop" is a bit misleading here since
    the spammer sender is rarely going to get their spam back which
    would be required for these to be loops. It might just be worth
    noting that (probably at 3.1, 3rd para where you almost but not
    quite say this).
    
    - p10 says "every complaint is sent immediatedly" which is not quite
    right, perhaps s/sent/forwarded/ would be more accurate?  (I might
    not read mail for the weekend and then the complaint won't be sent
    "immediately" for example.)
    
    - (p10, last para) If there's evidence that message recipients
    *often prefer* "this method" then referencing that would be good,
    otherwise this reads like it might be just a self-serving claim.
    (I'm not saying it is, I'm just saying how it looks.) More
    generally, supplying references to studies etc. that backup the
    claims made as to user preferences and effectiveness of the various
    options would make this a much more convincing read. (I understand
    that such studies may not typically be openly available in this area
    - however that does substantially weaken the claims made.)
    
    - p11, presumably real usability studies will take account of
    selection bias, so s/average// would seem slightly better.
    
    - p11, last para - this reads like having mailbox providers also
    provide an MUA or plug-in or whatever is an unqualified good thing.
    I think that's a little overstated, since the ability to be migrate
    between mailbox providers is also a (conflicting) good thing. It
    might be good to note that there are downsides to having a mailbox
    provider provide s/w to end users as well.
    
    - p12, I'm not quite sure what "keyed to" means here.
    
    - p16, the bullets at the top - the 4th last bullet says "other
    unspecified stuff" basically which is fine, but then subsequent
    bullets are listing "optional" things - I can't see how "other
    unspecified stuff" can be anything except optional, so I suggest
    marking that bullet as optional as well.
    
    - p16, section 3.6.1 is titled "IP validation" but makes no mention
    at all of IP, suggest changing the title to "Re-validation" maybe?
    
    - p17, 1st para: 3.6.2 talks about validating the addresses
    "associated with an IP", and 3.6.3 talks about "one's own IP" - I
    think this is showing up a set of IPv4 specific assumptions that
    have been made in these systems that will be changing with the
    deployment of IPv6 or maybe CGN and would suggest that rephrasing
    sentences like this to not refer to IP, except where that's really
    needed would be an improvement.
    
    - p19, point 3 says "a list of IP addresses" but I don't get why
    this might not be based on mail domain names or FQDNs as well (esp.
    with DKIM). In the same bullet, I don't think the mechanisms given
    "prove" ownership (if we ever "own" IP addresses?), so saying that
    these are checks that tend to get made would be a better phrasing.
    
    - p22, is keeping the "customer" happy the right phrase here?  The
    complainant is probably not a customer of the feedback consumer.
    
    - p22, s/broken down/analysed/ would be better
    
    - p22, seems like there's an assumption in 4.3.2, para 2, that an IP
    address is the same as a server which isn't really the case these
    days and I guess can cause problems with IPv4 addesses and maybe
    more with IPv6. I'd say just calling out that this is generally
    assumed these days (if that's the case) is enough at this point,
    though I do wonder how VMs of various kinds are affected by this.
    
    - p22, 432, 3rd para - at the end you use the term "problem
    customers" but its not quite clear that you're referring to
    problematic customers of the ESP sending mail that generates more
    complaints than most, or if you're referring to a complainant that
    complains more than most (the former I assume).
    
    - p23, I'd be interested in some backup as to why a 2% complaint
    rate is grounds for immediate blocking. Has anyone published data
    about best practices or what some large mail senders/receivers
    actually do?
    
    - p23, I don't think you really mean "smallest of users" since
    height is probably not well correlated with email behaviour:-)
    Perhaps "Even a feedback consumer with very minimal demands..."  
    or something?
    
    - p24 - s/originating sending/originating/ ?
    
    - p25 - s/sent from/sent/ in the bullet at the top of the page
    
    - p33 - I suggest s/take responsibility/take some responsibility/
    which was the semantic understood (by me at least:-) in the DKIM WG.
    
  5. Russ Housley: Discuss [2011-10-20]:
        
      Please reword the Abstract to remove the phrase "contributed to the
      IETF standards repository".  Since this is an Informational document,
      I believe this phrase will be confusing.  Suggestion:
    
       This document was originally produced by the Messaging Anti-Abuse
       Working Group (MAAWG), a trade organization separate from the
       IETF.  The original MAAWG document was published in April 2010.
       This document is being published as an Informational RFC to make it
       widely available to the Internet community and simplify incorporation
       of this material into IETF documents. 
        
  6. Pete Resnick: Comment [2011-10-13]:
    There was some last call discussion that indicating that some people found the
    "About MAAWG" paragraph in the Abstract untoward. Personally, I think it would
    be better to put the paragraph in the Acknowledgments section, or it could be
    simply put as a paragraph in the References section under reference [1].
    
    These are recommendations from MAAWG, and they are being published as an
    informational, non-consensus document so that a WG can refer to the document.
    Such a WG may agree with all of the recommendations, but more likely will have
    some alternative advice when referring to this document. The IESG should decide
    whether an IESG note explaining this is necessary, but I think the standard
    template for a non-consensus document ("This document is not an Internet
    Standards Track specification; it is published for informational purposes. It
    has been approved for publication by the Internet Engineering Steering Group
    (IESG).") is probably sufficient.
    
    I have an RFC Editor note to change the page header from "CFBL BCP" to "CFBL
    Recommendations". If the authors wish something different, they are free to
    suggest.
  7. Peter Saint-Andre: Comment [2011-10-19]:
    The definition in Section 1 has one instance of "spam" (all lowercase) but in
    the remainder of the document aside from Appendix C the only form used is "Spam"
    (initial caps).
    
    In Section 3.2, does "proprietary desktop client" exclude open-source
    implementations?
    
    In Section 3.5, why not cite RFC 2142? Such as: "best sent to abuse@ or
    postmaster@ the domain in question, per [RFC2142]".
    
    Appendix A.2 cites RFC 5965 and two websites as sources of canonical
    documentation for ARF, one of which points to draft-shafranovich-feedback-
    report-01 whereas the other points to draft-shafranovich-feedback-report-05. How
    is a developer to know which specification is in fact canonical? Please just
    point to RFC 5965 for documentation and to the websites for additional
    information.
  8. Robert Sparks: Discuss [2011-10-18]:
        This is a discuss-discuss. No action from the editors is requested at this time.
    
    Pete's comment indicates this is intended to be published as a non-consensus
    document
    (even though it's been last called). That would mean 2nd paragraph of
    boilerplate (per 5741
    section 3.2.2) would be:
       This document is a product of
    the Internet Engineering Task Force (IETF).  It has been
       approved for
    publication by the Internet Engineering Steering Group (IESG).
    
    And would _not_ contain "It represents the consensus of the IETF community."
    
    Is that the intent? If so, how does that get captured and passed to the RFC
    Editor? 
        
  9. Sean Turner: Discuss [2011-10-17]:
        <process weenie>
    
    This draft contains the following restrictions on publication from 6.c.ii of the
    TLP:
    
       This document may not be modified,
       and derivative works of it may not be created, and it may not be
       published except as an Internet-Draft.
    
    I'm thinking you meant to include the text from 6.c.i:
    
       This document may not be modified, and derivative works of it
       may not be created, except to format it for publication as an RFC
       or to translate it into languages other than English.
    
    Otherwise, it can't be published as an RFC.
    
    Need to split references between normative and informative.  If they're all one
    kind just put informative or normative in front of references in the title.
    
    Needs an IANA Considerations section.  If there are none, then the section can
    simply be:
    
       IANA Considerations
    
       None
    
    </process weenie>
    
    Pete: Are you planning on publishing it with this boiler plate:
    
      This document is a product of the Internet Engineering Task
      Force (IETF).  It represents the consensus of the IETF community.
      It has received public review and has been approved for publication
      by the Internet Engineering Steering Group (IESG)."
    
    or this boiler plate:
    
      This document is a product of the Internet Engineering Task
      Force (IETF).  It has been approved for publication by the Internet
      Engineering Steering Group (IESG)." 
        
  10. Sean Turner: Comment [2011-10-17]:
    s*: r/paper/document  Normally I-Ds/RFCs use document rather than paper.  So
    much more official ;)
    
    s1: Complaint Feedback Loop - There isn't a taxonomy section so maybe it should
    just be "See Overview section." ?
    
    s1: FBL - I had to chuckle there's an extremely long list of acronyms not used
    and they got left out - why mention this one?  BTW - fbl it's in s4.1 step 2 and
    in s4.4 ;)
    
    s*: The concept of the loop is odd in that spammer isn't really going to be in
    the loop.  In fact, you want to get rid of them.
    
    s2: Uses the term authorized Feedback Consumer.  The definition in s1 didn't
    make any distinction between Feedback Consumers.  I guess this my round about
    way of asking if all Feedback Consumers are authorized?
    
    s3.3: "keyed to" maybe "assigned to"?
    
    s3.4.2: r/approved entity/authorized entity - to match s2.
    
    s3.4.1 & 3.4.2: Often folks quote the Fair Information Practices when dealing
    with privacy issues.  Maybe instead of munging them together in the terms of use
    you could just list them like:
    
     - Notice and Consent:
     - Collection Limitation:
     - Use/Disclosure Limitation:
     - Retention Limitation:
     - Accuracy:
     - Access: 
     - Security:
    
    I've got no idea how you'd implement access, because of course spammers want to
    know what people have said about them.  Then again maybe they don't because then
    you could track them?
    
    s8: Update references to RFC 4871 to RFC 6376.

draft-haluska-sipping-directory-assistance

  1. Jari Arkko: Comment [2011-10-20]:
    I'm not sure I understand why a document that says "here's one way of using IETF
    protocols for <blaah>" and "here are some unmet requirements for <blaah>" can be
    considered as harmful for an IETF working group, even if that working group is
    focusing on the same space. I think a note with pointer to the IETF work would
    be more reasonable reaction in this case.
    
    But I don't work in this field, so maybe I'm missing something obvious.
    
  2. Adrian Farrel: Discuss [2011-10-18]:
        As this docuent stands, I support Robert's 5742 review. According to
    5742, I think Robert's feedback to the ISE should include the request
    that the IESG should be allowed to add an IESG note to the document
    in the event that the ISE decides to publish it.
    
    I also think it would be helpful (although not required by 5742) to
    clarify "at this time." Does the IESG forsee a time at which publication
    would be OK? 
        
  3. Adrian Farrel: Comment [2011-10-18]:
    I suspect that parts of this document could have been acceptable for
    publication, but the document has tried to do too much and cover too
    much ground.
    
    To some extent, this can be seen from the mixed message about the
    purpose of the document.
    
    The Abstract says:
    
       This document aims to identify how Operator and Information Services
       can be implemented using existing or currently proposed SIP
       mechanisms, to identity existing protocol gaps, and to provide a set
       of Best Current Practices to facilitate interoperability. For
       Operator Services, the intention is to describe how current operator
       services can continue to be provided to PSTN based subscribers via a
       SIP based operator services architecture. It also looks at how
       current operator services might be provided to SIP based subscribers
       via such an architecture, but does not consider the larger question
       of the need for or usefulness or suitability of each of these
       services for SIP based subscribers.
    
       This document addresses the needs of current Operator and
       Information Services providers; as such, the intended audience
       includes vendors of equipment and services to such providers.
    
    But Section 1 says:
    
       Implementing Operator and Information Services with SIP will require
       the exchange of certain information, and possibly the use of
       specialized capabilities which are not normally required for other
       types of calls. This document aims to identify such information, and
       stimulate discussion about how this information could be exchanged.
       Existing mechanisms will be used where appropriate, and currently
       existing proposals will be favored over new extensions.
    
    That is a lot of different purposes, and some of them run flat up
    against core IETF work as Robert indicates.
    
    I think that if you had limited yourselves to
    
       This document aims to identify how Operator and Information Services
       can be implemented using existing or currently proposed SIP
       mechanisms, and to provide a set of Best Current Practices to
       facilitate interoperability.
    
    you would probably have found more suport for the document and possibly
    support from within the working group.
  4. Stephen Farrell: Comment [2011-10-17]:
    I agree with the proposed 5742 response, i.e. to recommend
    not publishing at this time.
    
    I also have some comments below that the authors might want to 
    take into account.
    
    - "MF" isn't defined/explained (p6, used twice), as are a bunch of
    other acronyms (ISUP, TNS, CIP, CSI...). Not sure which need
    definitions but I guess some at least do.
    
    - p22 - listening to "a scrambled version" of the call seems odd -
    is that a real service? what kind of "scrambling"?
    
    - 2nd last para of p29 says when you've no identity info, you "MAY
    be unable" to do stuff - would that be better with a "SHOULD or
    MUST NOT implement" since attempting to do so would presumably go
    against the caller's wishes or the inter-domain agreements between
    the various providers?
    
    - There are many occurrences of phrases like "in North America."
    (`grep America draft-haluska-* | wc` -> 38; Europe occurs twice and
    Asia not at all.) So many in fact, that I wonder if the title
    should be changed to reflect that - this really seems like a North
    American oriented document. (Having said that, I've no real clue as
    to whether the actual content is more broadly applicable or not.)
    
    - Section 9.16 seems to depend on sending an obfuscated URI for the
    "whisper" audio. That should raise a bunch of security
    considerations, but those are not addressed, at least in 9.16.
    There would also be questions as to when that audio can safely be
    deleted, and potential privacy concerns if it is not promptly
    deleted that don't seem to be addressed.
    
    - Title of 9.20 - s/With Holding/Withholding/ and similarly within
    the body of the section s/with held/withheld/ etc
    
    - The "intercept-*" sip URIs described in 11.4.1 seem odd.
    Wouldn't doing that require these to be specially registered in
    some IANA registry that every SIP UA and other SIP implementation
    knows about in order to prevent fairly nasty attacks?
    
    - I didn't read the "collect call" and 3rd party billing things
    very closely but they seem fairly ripe for fraud. A section showing
    why this is not the case would seem to be missing, especially as
    11.5 says that collect calling could be done without human
    intervention. I guess I'd start thinking about attacking this by
    re-routing the RTP streams maybe but the point is that if the
    authors have thought through the potential for fraud, I'd have
    expected some text about that.
    
    - The security considerations basically says "look at the
    references and the rest is TBD" but in more words;-) That may be ok
    in a document like this, but its not very satisfactory that the
    proposed services have been defined down to the level of message
    flows but with no security analysis being provided.
  5. Pete Resnick: Comment [2011-10-18]:
    I agree with Adrian that we should also ask for the opportunity to include a
    statement if the ISE decides to publish.