IESG Narrative Minutes
Narrative Minutes of the IESG Teleconference on 2011-10-20. These are not an official record of the meeting.
Narrative scribe: John Leslie (The scribe was sometimes uncertain who was speaking.)
Corrections from:
1 Administrivia
2. Protocol Actions
2.1 WG Submissions
2.1.1 New Items
Telechat:
Telechat:
Telechat:
Telechat:
Telechat:
Telechat:
Telechat:
Telechat:
Telechat:
Telechat:
2.1.2 Returning Items
2.2 Individual Submissions
2.2.1 New Items
Telechat:
2.2.2 Returning Items
3. Document Actions
3.1 WG Submissions
3.1.1 New Items
3.1.2 Returning Items
3.2 Individual Submissions Via AD
3.2.1 New Items
Telechat:
Telechat:
3.2.2 Returning Items
3.3 IRTF and Independent Submission Stream Documents
3.3.1 New Items
Telechat:
3.3.2 Returning Items
1245 EDT break
1250 EDT back
4 Working Group Actions
4.1 WG Creation
4.1.1 Proposed for IETF Review
4.1.2 Proposed for Approval
Telechat:
Telechat:
4.2 WG Rechartering
4.2.1 Under evaluation for IETF Review
4.2.2 Proposed for Approval
5. IAB News We can use
6. Management Issues
Telechat:
Telechat:
7. Agenda Working Group News
Adrian: point you at Michelle's email
David: what is the issue?
Adrian: pasted into jabber
Robert: I have another short item
Robert: further work to do
Russ: NFS-one is regular discuss resolution
Robert: gap in the tracker: number of documents where tracker doesn't know which stream: how is it getting set right now
Cindy: WG docments are known to be IETF stream
Russ: others manual by Secretariat
Robert: would it work to have AD set stream at same time as setting status? should be put any significant effort into fill stream-unknown documents?
Russ: level-of-effort question
Robert: for recent documents, not huge but not trivial, multiple days
Russ: does tracker keep telechat agendas for the past -- could you walk through things that appeared in section 2, e.g. -- anything more seems to be diminishing-return
Robert: I think we can only ask which section if it appeared on agenda today
Russ: seems sufficient
1335 EDT Adjourned
(at 2011-10-20 07:30:25 PDT)
draft-ietf-eai-rfc5337bis-dsn
I would like to see Appendix A consolidated to show "Changes from RFC 5337" and retained in the document.
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.
draft-ietf-eai-rfc5336bis
There are id nits...
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?
#1) Do the authors also wish to make RFC 5336 Historic? #2) Please add a section that lists the difference between RFC 5336 and this document.
draft-ietf-eai-rfc5335bis
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.
It would be nice to concentrate section 7 into "changes from RFC 5335" and retain it in the document.
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.
#1) Do the authors also wish to make RFC 5335 Historic? #2) Please add a section that lists the difference between RFC 5335 and this document.
draft-ietf-dnsext-rfc2672bis-dname
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.
It would be useful if you added an appendix that summarizes the changes to DNAME and CNAME between this document and previous documents.
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
- 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?
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).
#1) Many times when a document obsoletes another there's a section in the new document that summarizes what's changed. Such a section would be nice to have in s1.
draft-ietf-nfsv4-federated-fs-dns-srv-namespace
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?
I'm not sure why the mount point conventions are needed.
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.
The Gen-ART Review by David Black on 26-Sept-2011 raises some
concerns that deserve a response. Please find the review at
http://www.ietf.org/mail-archive/web/gen-art/current/msg06749.html.
I agree with the concerns regarding the SRV record and the mount points.
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?
I support Peter's discuss.
s4.2: r/recommended/RECOMMENDED in the following: As for the other attributes in fs_locations_info, the recommended approach is for a client to make its first possible contact with any ...
draft-ietf-grow-no-more-unallocated-slash8s
Support Stephen's DISCUSS and agree with Adrian's COMMENT.
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.
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?
Windmill tilt: I see no reason that this can't be a Proposed Standard in that it is giving implementation advice.
draft-ietf-sidr-ghostbusters
This document could only have been written by Randy :-)
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.
Please consider the comments from the Gen-ART Review from Miguel Garcia on 19-Sep-2011. The review can be found here: http://www.ietf.org/mail-archive/web/gen-art/current/msg06741.html
I was left a bit confused about what precisely is *the* Ghostbusters Record. I got lost as to what was the record, and what was the payload of the record. It would have helped me if in addition to, "The Ghostbusters Record conforms to the syntax defined in [I-D.ietf-sidr-signed-object]", you would have added the sentence "The payload of this signed object is a severely profiled vcard", and maybe having something in the "Additional Information" in the media type registration that it is the SIDR signed-object, not the vcard data, that is being defined as the media type. Maybe folks who work in this space would not have gotten confused, but as random MIME schmo, it took me going back and forth a few times to be clear on what was what.
draft-ietf-appsawg-rfc3462bis
Concur with Russ' discuss.
Cleared my Discuss after discussion
This should be going to Internet Standard under the new process.
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>
#1) Do the authors also wish to make RFC 3462 and or 1892 Historic? #2) I'll leave it to Pete/Barry if the additions as a result of discuss #2 require coordination with ietf-types@ietf.org
draft-ietf-ccamp-attribute-bnf
I want to build on two comments that were originally offered in the Gen-ART Review by Vijay Gurbani on 17-Oct-2011. Section 2 includes an group of indented paragraphs, and all but one of those paragraphs contains an RFC 2119 key word. Please consider making the "must" in that paragraph into "MUST". Section 3 includes an group of indented paragraphs, and all but one of those paragraphs contains an RFC 2119 key word. Please consider making the "must" in that paragraph into "MUST".
draft-ietf-mpls-tp-li-lb
Please run the spell checker over this document.
- 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?
draft-gundavelli-v6ops-pmipv6-address-reservations
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,
I think this is a useful document. It seems like it should have "Updates: RFC 5213" though?
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.
Strike section 2.1. 2119 is not used in this document.
draft-melnikov-mmhs-header-fields
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.
draft-jdfalk-maawg-cfblbcp
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.
draft-haluska-sipping-directory-assistance
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.
I agree with Adrian that we should also ask for the opportunity to include a statement if the ISE decides to publish.