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.

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:

Amy: LastCall ended today; open not here; no discusses, hearing no objection, approved

Pete: point-raised, please... several comments about consolidated list of changes, do you want a blow-by-blow in this document

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.

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

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.

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

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.

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?

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.

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?

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.

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"

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

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.

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:

Amy: LastCall ended today; a couple of discusses

Pete: same downref issue, I'll deal with it similarly, AD-followup is fine for this

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.

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.

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

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?

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.

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.

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.

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

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.

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?

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.

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.

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.

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.

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?

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

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.

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?

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.

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.

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.

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.

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>

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:

Amy: open not here, number of discusses

Pete: Robert, I can't find an implementation report, there might not be one

Robert: one part does exist; I'll clear on that; if we land an Draft Standard, there should be a note

Pete: question whether we go straight to Standard: WG approved this before change to process; Russ, what is the process

Russ: four-week LastCall

Pete: is there a reason not to approve it now, and start transition process

Russ: four-week LastCall anyway

Pete: do we leave it in abeyance for four weeks

Peter: it's recycling at Draft

Pete: the only difference is it could start in the RFCed queue now; the reason changes were made was changes they want to make available to other WGs

Pete: did two-week LastCall because it was recycling at draft: we removed a requirement

Jari: the part of 6410 doesn't speak of this case

Russ: it was supposed to be saying "use the process above"

Jari: it's OK, I'm with you now

Russ: we could grant an exception and continue the LastCall for another two weeks, but I'd rather not do that the first time we use the process; LastCall should explain the situation; it goes back to LastCall requested; needs to come back to a telechat

Pete: I will check with APPSWG, see if they howl

Russ: their choices are Proposed or Full, which do they want? I suggest you don't approve as Proposed

Pete: this will go to LastCall requested, after I pass it by WG

Amy: we'll put this into AD-followup; then you change status when after discussing with WG

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:

Amy: open not here; no discusses, hearing no objection, approved

Adrian: RFCed notes are OK; Russ, text you refer to is a direct quote from an earlier RFC; good to go

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

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:

Amy: one open, Wes not with us yet; no discusses, hearing no objection, approved

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,"

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.

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

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.

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.

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

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?

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.

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!

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.

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?

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)

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

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.

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.

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?

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

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:

Amy: LastCall ended today

Pete: think I have an answer re changes to the Abstract, they will resubmit with the correct copyright statement

Jari: which will you use, I'm not happy with the no-derivatives one

Russ: they are retaining change-control

Pete: Stephen's point that there's no point to publish at all if it's easily referenced elsewhere; I believe it's easier to reference as an RFC...

Pete: is everyone OK with "no derivative works"

Jari: I can hold my nose on that, but the Abstract language seems wrong, if you fix that, I'm OK

Pete: I'm OK if you want to hold a discuss until that change is made

Jari: I'll clear now

Pete: only issue left is what the boilerplate will say: IMO this is not a product of the IETF, I think that should change

Russ: didn't we LastCall this document: if we did, this is a product of the IETF

Pete: I intend to lean toward: review without change-control doesn't make it an IETF document

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.

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?

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.

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.

Russ Housley (General)--- timezone database, Olsen started in 1980's, nearing retirement, IANA chosen as new home, suit filed against Olsen and one other, database taken offline, pro-bono legal defense has been arranged, ICANN brought database on-line October 14
Pete: is there any way we can honor Dr. Olsen
Russ: so far he says "premature"... we'll do something... would love for him to be at plenary... we'll see what happens

Pete Resnick (Apps)--- couple of personnel issues

Dan Romascanu (O & M)---

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

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.

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

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.

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.

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.

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

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.

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?

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?

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.

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"

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

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.

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.

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.

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.

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

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

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?

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.

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.

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.

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.

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?

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.

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.

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.

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.

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.

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>

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

- 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

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?

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,

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.

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

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.

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.

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

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.

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?

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.

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

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!

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.

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?

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.

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.

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.

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.

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?

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

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.

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.

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?

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.

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.