Shepherd writeup
rfc8494-08

draft-melnikov-email-over-pmul is proposed for publication as an Informational Independent Submission RFC.
                                                                             
It describes a proprietary implementation of Multicast Email (MULE) over P_MUL, a reliable multicast protocol also known as ACP-142. The document is clear that the work is not the output of the IETF and is presented chiefly for the purposes of facilitating inteoperable implementations and debugging live networks.

The document was first brought to the ISE as revision -01 in September 2017. Since then it has had detailed review on behalf of the ISE by Sean Turner, Barry Leiba, amd Dave Crocker. Final review by the ISE led to a number of changes (largely of tone and editorial in nature).

The authors note that there is no relevant IETF WG and so this document was never submitted for publication on IETF Stream. They did advertise the document on ietf-smtp@ietf.org, but didn't receive any reviews there.


NOTE WELL. This document asks IANA to create a codepoint registry with allocation policy 'Specification Required' under the care of a Designateed Expert. This document and the ISE are clear that the ISE is responsible for appointing the initial DEs, for finding substitute DEs in the future, and for acting as backstop if DEs cannot be foun or are unresponsive. This has been discussed with IANA who have agreed the process.

The initial reviews by the three reviewers are presented below for information.

=============

Review of:     Mail Transfer Protocol over ACP 142
I-D:           draft-melnikov-email-over-pmul-01

Reviewer:      D. Crocker
Review date:

Summary:

    The draft specifies an adaptation of SMTP, to operate over a 
multicast medium, specifically ACP 142.  It leverages the lower-layer, 
multicast router, for fan-out to multiple receiving MTAs.  It further 
adapts to reduced interaction, for environments that restrict the 
ability of receiving MTAs to respond in real-time.

    The draft is submitted for Independent stream publication, so that 
the primary acceptance criteria are: basic relevance to the Internet 
technical community, absence of conflict with existing IETF work, and 
general specification writing quality.  The draft satisfies all three: 
The draft is generally well-organized and well-written, although some 
substantive improvements are recommended, below, including one technical 
design concern I consider major. It seems likely that ACP 142 is of 
limited interest to the general Internet technical community, since it 
is used in a highly constrained administrative environment (some 
military); however a multicast-based application protocol design should 
very much be of interest to the community.  Further I believe there is 
no related IETF work in this space.

The design seems to have one major technical flaw, concerning 
reliability.  The document does not say this explicitly, but it relies 
solely on the reliability of the lower-layer multicast transport for all 
reliability services, except to send a failure DSN.  That is, it changes 
the email application protocol from an ACK model of reliability to a 
NACK model -- the absence of a NACK is taken to mean that transmission 
was successful.  Such a reliance on lower layers for all aspects of 
reliability has a long history of being problematic, dating back to the 
Arpanet's NCP (TCP-equivalent) relying on the IMP packet switches. These 
early problems were the reason that TCP and IP do not rely on the 
underlying network for all aspects of reliability.  Similarly, Internet 
application-level protocols include connection-validation mechanisms in 
order to detect a variety of lower-layer problems, such as connection to 
the wrong host.  The lesson is that the upper-layer needs to have its 
own, active method of communicating success, as well as failure.  The 
easy solution to this, given the details of the current draft, is to 
require a DSN for ALL messages, not just messages that fail; this will 
increase traffic from receiving MTAs, but the current draft already 
requires some equivalent traffic, so the change is in degree, not kind.

It appears that detail is missing, concerning ACP 142-specifics, for use 
with MULE (or P_MUL, I'm not sure whether it's one or the other or both.)




Detailed Comments:

> Abstract
> 
>    ACP 142 defines P_Mul, which is a protocol for reliable multicast in
>    bandwidth constrained and delayed acknowledgement (EMCON)
>    environments running over UDP.  This document is a specification of
>    the basic protocol for electronic mail transfer over P_MUL.  It also
>    described how to gateway this basic protocol to/from Simple Mail
>    Transfer Protocol (RFC 5321).
>
> Table of Contents
...
>    3.  Gatewaying from Internet Mail . . . . . . . . . . . . . . . .   4


"Gatewaying" involves a translation between two, related-but-different 
environments.  There should be some care in offering a model that 
distinguishes the translation activity from the two, separate, 'native' 
transfer activities. Making the distinction explicit usually simplifies 
a specification or, at least, makes it easier to understand.  A possible 
diagram for this is offered below.

The current form of the draft implies that multicast is only a last-hop 
tail and always gets translated to/from regular Internet Mail -- that 
is, SMTP semantics.  Perhaps that is the reality for the current 
implementation but what if there were an entire, multi-cast based email 
network.  Would it still be translating everything to/from regular SMTP 
semantics or would it stay in MULE packaging?  I'd expect the latter; if 
the decision is to cast MULE as only a stub activity to native SMTP, 
then this should be stated explicitly.

In terms of documenting a translation process, this requires 
specifications for each environment, with the translation mechanism 
being distinct.  We have specification for regular SMTP. The current 
spec talks only about the translation, without having a clear 
specification for the non-SMTP environment.  The reader gets details 
about that other environment, but not in a distinct, coherent fashion.

It appears that the email object is the same in both environments -- 
this should be stated explicitly -- so that it is only the email 
transfer mechanisms that have difference. This should be made explicit. 
(BTW, having a common message object means that there is an argument 
that, therefore, both environments are Internet Mail. cf, RFC 1775...)

So, I'm suggesting a documentation style that has:

      Internet Mail <--> Gateway <--> MULE

and document MULE as distinct from the Gateway processing.  (This is 
different from the multi-cast diagram the draft shows, farther down. (I 
suspect that that existing diagram is of the MULE 'network'.  So the 
combined diagram would be something like:

                         +-------+                   +-------+
                         | MTA 1 |<-\             /->| MTA 3 |
+-------+     +-----+   +-------+   \ +-------+ /   +-------+
| MTA A |<--->| G/W |<--------------->| Router|<
+-------+     +-----+   +-------+   / +-------+ \   +-------+
                         | MTA 2 |<-/             \->| MTA 4 |
                         +-------+                   +-------+

                     |< -------------- MULE ---------------->|



> 1.  Introduction
> 
>    P_MUL [ACP142A] is a protocol for reliable multicast in bandwidth
>    constrained and delayed acknowledgement environments running over
>    UDP.  The objectives of this protocol are first to take advantage of
>    the bandwidth saving feature of using the multicast service as
>    supported by modern computer networks and second to allow message
>    transfer under EMCON conditions.  EMCON (Emission Control) or "Radio
>    Silence" means that, although receiving nodes are able to receive
>    messages, they are not able to acknowledge the receipt of messages.
> 
>    The objective of this protocol is to take advantage of multicast
>    communication for the transfer of messages between MTAs (Message
>    Transfer Agents) on a single multicast network under EMCON
>    conditions.  EMCON condition means that a receiving node is able to
>    receive messages, but it cannot - for a relitive long time (hours or
>    even days) - acknowledge the received messages.

Other than the summary term "reliable multicast", the draft does not 
give any summary of the functional characteristics of the reliability 
mechanism. Especially given the signaling constraints imposed by having 
EMCON, these reliability characteristics are likely to be quite unusual 
and likely to have significance at the email transfer level.  The 
specification should bring these details out explicitly.  Note that 
while receiving MTAs have highly restrict response opportunities, they 
do have /some/.  However the characteristics of such response traffic, 
in terms of frequency/latency or amount, are not provided, but should be.


>    This illustrates a simple multicast scenario, where the same message
>    has to be sent from MTA 1 to MTA 2 and to MTA 3.
> 
>                                             +-------+
>                                          /->| MTA 2 |
>               +-------+       +-------+ /   +-------+
>               | MTA 1 |<----->| Router|<
>               +-------+       +-------+ \   +-------+
>                                          \->| MTA 3 |
>                                             +-------+
> 
>    Typical MTA Configuration
> 
>                                  Figure 1
> 
>    Using a multicast instead of an unicast communication service in the
>    above MTA configuration only one message transmission from MTA 1 to
>    the Router is required, instead of two as required with unicast.
>    This saves the transmision of one message and thus network bandwidth
>    utilisation.  Depending on the network bandwidth (in some radio
>    networks less than 9.6 Kb/s) this saving can be of vital importance.
>    The saving in bandwidth utilisation becomes even greater with every
>    additional receiving MTA.
> 
>    As P_Mul employs a connectionless transport protocol to transmit
>    messages, the reliable message transfer is guaranteed even in those
>    cases, when for a certain period of time one or more of the receiving
>    MTAs are not able or allowed to acknowledge completely received
>    messages.

This paragraph doesn't make much sense to me.  The "As" at the beginning 
means that the first part should motivate/justify the latter part and I 
don't see how "connectionless transport" has any relationship to 
"reliable message transfer".

My guess is that the intended meaning is more along the lines of "P_Mul 
employs a ....messages, that guarantees reliable message transfer, even 
in those cases..."

Note however that the draft needs to deliver on that promise by 
explaining how reliability is achieved.


> 
>    This protocol specification requires fixed multicast groups and a
>    well known knowledge at each participating node(MTA) about the group
>    memberships to one or more multicast groups of each participating
>    node.
> 
>    This document defines application protocol MULE (Multicast Email) for
>    transferring Internet Mail messages [RFC5322] over ACP 142 P_Mul.

Consider promoting the name MULE into the title, since it is the handle 
for what is being specified.

(BTW, since mules can't reproduce, there is some nice irony in having 
the term used to refer to a multicast mechanism...)




> 2.  Conventions Used in This Document
> 
>    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
>    "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
>    document are to be interpreted as described in [RFC2119].
> 
>    This document is also using terminology from [RFC5321].

I feel obligated to make a plug for citing RFC 5598, since some of its 
model and terminology are used here...

In general, the draft should use terminology a bit more carefully.  For 
example, when it says 'recipient' it seems to actually mean 'receiver'. 
That is, it is referring to a receiving MTA rather than the addressed 
end-user.  (Casual, daily use conflates these commonly, but a 
specification should be more careful.)



> Wilson & Melnikov       Expires February 11, 2018               [Page 3]
> 
> Internet-Draft             Email over ACP 142                August 2017
> 
> 
> 3.  Gatewaying from Internet Mail
> 
> 3.1.  Sending Internet Messages
> 
>    When the content type for a message is an Internet message content
>    type (which may be 7bit, 8bit or binary MIME), this is transported

This sentence is a bit confusing.  "Content-type" is a MIME term of art, 
not a 'message' term.  A 'message' does not have a content-type.  A 
message 'body' or a MIME 'body-part' does.  It looks like the applicable 
term that is used in SMTP service extensions, to cover what is meant 
here, is "content body".

Language that is pedantic but precise might be:

      [ACP142A] can be used for transmitting any Internet Mail message 
content body that can be transferred by SMTP using 7bit, or 8bitMIME or 
BINARYMIME.


However from the later discussion of Binary, I think the above statement 
should NOT reference it, since it's only supported by bilateral agreement.



>    using ACP 142 [ACP142A].  Firstly, for each mail message a BSMTP-like
>    payload is formed, as described in Section 3.1.1.  Secondly, the
>    created payload is compressed and encoded as specified in
>    Section 3.1.2.  Thirdly, the compressed payload is sent by P_Mul as a
>    series of Address_PDU and one or more DATA_PDUs.  When the message
>    has an associated MT-PRIORITY value [RFC6710], the
>    MappedPriority(value) is included as the Priority field of
>    corresponding ACP 142 PDUs, including Address_PDU, DATA_PDUs,
>    DISCARD_MESSAGE_PDU.  Here MappedPriority(x) is defined as "-1 * x +
>    6".

Personal preference for specification style:  When a list is given -- 
especially a procedural sequence -- present it in list form, numbered if 
it is a sequence. This facilities comprehension and later reference.


>    The sender of the message can assume that the receiver supports the
>    following ESMTP extensions: DSN [RFC3461], SIZE [RFC1870], 8BITMIME
>    [RFC6152], MT-PRIORITY [RFC6710], DELIVERBY [RFC2852].

I suspect that 'can assume' is wrong.  More likely is that is actually 
meant as a normative set of baseline capabilities; so it needs to be 
stated that way, with a MUST.

If it is /not/ a required set, then what happens if the sender makes the 
assumption of support but the receiver doesn't actually do the support? 
Especially in an environment with high latency for responses, I'd expect 
this to kill interoperability.


>    The receiver MAY accept BINARYMIME [RFC3030] SMTP extension.  This is
>    a matter for bilateral agreement.  As the message content size can

Bilateral agreement is another term for "outside the standard".  Private 
parties can agree to anything they want. When a spec says something like 
bilateral agreement, it is not specifying any technical or operational 
detail that is useful.

So, here, the "MAY" is not a protocol option.  Rather, it's permission 
to have an out-of-band agreement between private parties.  Hence, it is 
a meaningless distraction from the substance of the specification.

The protocol standard form of the above is more like:

    A sender MUST NOT rely on a receiver's support of BINARYMIME 
[RFC3030] SMTP extension, in the absence of an explicit, bilateral 
agreement.


>    always be determined from the compression wrapper and the size of the
>    envelope, no special handling is needed for binary messages.
> 
>    The set of ACP 142 destinations for the message is derived from the
>    next hop MTAs for each of the recipients.

Where is the specification detail for doing this mapping?  It needs to 
be provided or cited.

Where is the rest of the detail for ACP 142-specific information, such 
as the contentType-ShortForm value to use?


> 
> 3.1.1.  BSMTP-like Payload construction
> 
>    MULE uses BSMTP-like payload which differs from BSMTP [RFC2442].
>    ESMTP is using capability negotiation, which is not practical when
>    EMCON is used, as there is no way for a recipient to return

Perhaps:  MULE is derived from BSMTP [RFC2442], with small 
modifications. As with BSMTP, ESMTP capability negotiation is not used. 
since receiver EMCON restrictions prohibit such real-time interaction.


>    capabilities before a message can be sent.  For that reason, there is
>    no point in including EHLO capabilities.  "MAIL FROM:" and "RCPT TO:"
>    prefixes can also be eluded in order to save a few bytes.
>
> 
>    For each received message, the corresponding BSMTP-like payload is
>    constructed as follows (Lines are terminated using CR LF):

Nit:  received -> transmitted


...


>    ABNF for the BSMTP-like payload is:
> 
> bsmtp-like-payload = envelope CRLF payload
> envelope = FROM-line 1*RCPT-line
> FROM-line = reverse-path [SP mail-parameters] CRLF
> RCPT-line = forward-path [SP rcpt-parameters] CRLF
> 
> payload = *OCTET
>           ; Conforms to message syntax as defined in RFC 5322 and extended in MIME

MIME seems not to be formally cited in the draft.

Payload has no syntactic delimiter at the end?  The basis for 
termination should be defined explicitly.


> OCTET = <any 0-255 octet value>
> reverse-path = <as defined in RFC 5321>
> forward-path = <as defined in RFC 5321>
> mail-parameters = <as defined in RFC 5321>
> rcpt-parameters = <as defined in RFC 5321>

The ABNF should come before the example...



> 3.2.  Error handling
> 
>    As MULE doesn't allow next hop MTA to return immediate Response Codes
>    for FROM-line or any of recipients in RCPT-line, MTAs that are
>    compliant with this specification that receive a message that can't
>    be delivered MUST generate a non delivery DSN report [RFC6522]
>    message which includes message/delivery-status body part [RFC3464]
>    and submit it using MULE to the FROM-line return-path address.
> 
>    TBC: Also need to describe how to handle FROM-line or RCPT-line
>    parameters that we don't understand.  Probably, they can be rejected
>    on receipt or be relayed to the final destination/gateway, which can
>    decide what to do with them.

I suggest -- maybe strongly -- that the MULE environment be defined to 
have mandatory support for a specific set of SMTP extensions and that 
the presence of any additional -- ie, not specified in MULE -- 
extensions MUST force message rejection, unless there is a private, 
bilateral agreement in place for support of the extension's use.

That is, define a simple, rigid environment and define variations as 
being outside the spec. This permits interoperability.  Any other 
approach threatens it.


> 3.3.  Use of BDAT
> 
>    If SMTP CHUNKING extension is used by the SMTP side, data from all
>    BDAT blocks is concatenated into continuous block and is used as the
>    message payload.  Use of BINARYMIME [RFC3030] might need to be
>    enabled in the FROM-line.

"used by by the SMTP side" probably is clear, but I can also imagine 
that it might not be.  To make a bit more clear, perhaps:

      If a message is received by a gateway, through SMTP transfers 
using the CHUNKING extension, the message is rebuilt by the SMTP 
receiving MTA into its complete, single, original form and is then used 
as a single MULE payload.


I suggest dropping the reference here to BINARYMIME, since the use of 
that extension is deferred to private, bilateral agreement.  That is, 
it's not part of the spec.


> 
>    BURL [RFC4468] SMTP extension only applies to SMTP Submission, so it
>    is already mapped to BDAT/DATA by the time it reaches MULE.

Huh?

This is not a Submission scenario.  Hence it is (or at least, should be) 
outside the scope of this draft.


> 
> 4.  Gatewaying to Internet Mail
> 
>    Gatewaying from ACP 142 environment to Internet Email is the reverse
>    of the process specified in Section 3.1.  Firstly, the message is
>    reassembled from one or more DATA_PDUs.  Secondly, if the
>    contentType-ShortForm value is 25, the BSMTP-like payload is

This contentType-ShortForm value is not specified in the ACP 142 
creation process.


>    extracted from compressedContent field and uncompressed as specified
>    in Section 3.1.2.  Thirdly, the BSMTP-like payload is converted to
>    SMTP transaction (see Section 3.1.1).  (The first line of the BSMTP-
>    like payload is prepended with "MAIL FROM:" and each following line
>    (until the empty line is encountered) is prepended with "RCPT TO:".
>    After skipping the empty delimiting line, the rest of the payload is
>    the message body.  This can be either sent using DATA or a series of
>    BDAT commands, depending on capabilities of the receiving SMTP
>    system.)

Again, I suggest putting a list of actions like this into a 
list/sequence format.


> 
> 4.1.  Error handling
> 
>    ESMTP extension parameters to MAIL FROM and RCPT TO SMTP commands
>    obtained from BSMTP-like payload are processed according to
>    specifications of the corresponding ESMTP extensions.
> 
>    Failures to extract or uncompres BSMTP-like payload are handled
>    according to ACP 142.
> 
> 5.  IANA Considerations
> 
>    IANA is requested to create a new registry "Multicast Email SMTP
>    extensions".  SMTP extensions registered in the "SMTP Service
>    Extensions" IANA registry can be registered in this new registry.
>    Registration procedure for the new registry is "Specification
>    Required".  Registration requests should include SMTP extension name,
>    status (see Section 5.1) and specification reference.


Hmmm.  This is interest.  First, good that the table is being defined. 
Second, I believe it is seeking to specify a subset of SMTP extensions 
that are required to be supported by implementations.  Language to that 
effect needs to be provided, preferably with some indication of that 
also in the name of the table; something like "SMTP Extension Support in 
Multicast Email".  Second, I think it is not necessary -- and might also 
invite divergence errors -- to have an entry cite the RFC specification, 
since that's already provided in the 'parent' SMTP service extensions table.

That is, the current table should be defined as listing a subset of the 
existing SMTP Service Extensions table (RFC 5321), to indicate which 
extensions MUST be supported by a MULE implementation.



> Wilson & Melnikov       Expires February 11, 2018               [Page 8]
> 
> Internet-Draft             Email over ACP 142                August 2017
> 
> 
> 5.1.  Mapping of existing SMTP extensions to MULE
> 
>    The following table summarizes how different SMTP extensions can be
>    gatewayed to/from MULE.  Each extension has one of the following
>    statuses: "required" (required to be supported on the SMTP side),
>    "disallowed" (incompatible with this protocol), "N/A" (not relevant,
>    because they affect commands other than MAIL FROM and RCPT TO.  Can
>    be used on the SMTP side) or "supported".

1. I am not sure I understand the difference between Required and 
Supported. I suspect it means that the gateway MUST generate the 
Required ones and MAY generate the Supported ones?  Otherwise, what is 
the point of saying the support is 'required' on the SMTP side?

2. Listing extensions that are /not/ to be supported highlights a 
problem with how this table is currently specified:  the implication is 
that it is attempting to be exhaustive and this will require it always 
be in sync with the parent, SMTP Extensions, table.  It need not do 
that.  That is, it only needs to specify the extensions that /are/ part 
of MULE, not those that aren't.  It it is not part of MULE, it is out of 
scope and, therefore, should not be mentioned.

3. The focus on the 'SMTP side' again raises a problem with not 
distinguishing gateway from native MULE:  There is nothing that 
specifies what MULE supports, although it's implied.  Hence I think that 
things get simpler if the table is cast as I've suggested above: "SMTP 
Extension Support in Multicast Email".  That is, as native MULE detail, 
with a column indicating that use is Required or Allowed.  Text 
specifying MULE implementation then dictates that it MUST generate all 
of the Required extensions and must accept all of the Required and 
Allowed extensions.  This applies to the MULE implementation in a gateway.



>    +---------------------+-----------+---------------------------------+
>    | SMTP Extension      | Reference | Status                          |
>    | Keyword             |           |                                 |
>    +---------------------+-----------+---------------------------------+
>    | SIZE                | [RFC1870] | Required                        |
>    |                     |           |                                 |
>    | 8BITMIME            | [RFC6152] | Required                        |
>    |                     |           |                                 |
>    | DSN                 | [RFC3461] | Required                        |
>    |                     |           |                                 |
>    | MT-PRIORITY         | [RFC6710] | Required                        |
>    |                     |           |                                 |
>    | DELIVERBY           | [RFC2852] | Required                        |
>    |                     |           |                                 |
>    | BINARYMIME          | [RFC3030] | Supported                       |
>    |                     |           |                                 |
>    | PIPELINING          | [RFC2920] | N/A                             |
>    |                     |           |                                 |
>    | CHUNKING            | [RFC3030] | N/A                             |
>    |                     |           |                                 |
>    | BURL                | [RFC4468] | N/A                             |
>    |                     |           |                                 |
>    | ENHANCEDSTATUSCODES | [RFC2034] | Supported (through DSN)         |
>    |                     |           |                                 |
>    | CHECKPOINT          | [RFC1845] | Disallowed                      |
>    |                     |           |                                 |
>    | RRVS                | [RFC7293] | Supported                       |
>    |                     |           |                                 |
>    | NO-SOLICITING       | [RFC3865] | N/A                             |
>    |                     |           |                                 |
>    | SUBMITTER           | [RFC4405] | Supported                       |
>    |                     |           |                                 |
>    | CONNEG              | [RFC4141] | Disallowed                      |
>    |                     |           |                                 |
>    | STARTTLS            | [RFC3207] | N/A                             |
>    |                     |           |                                 |
>    | AUTH                | [RFC4954] | N/A (MAIL FROM parameter is     |
>    |                     |           | supported)                      |
>    +---------------------+-----------+---------------------------------+

=============

Sean Turner

Alexey asked me to review this draft.  I’m no mail expert like Alexey, but I've
got some experience with ACPs.

Comments:

s1, penultimate paragraph: Good to point out that the groups need to be established
for this to work.  The only thing I think that’s missing there is that they need to
be established before messages start getting sent.  I can see that it might be
implied but it’s not explicit stated.

s3.2: any particular reason you didn’t use the CMS Compressed Data content type from
RFC 3274?  AH! s,o the point is that you want to avoid sending the algorithm OID
(and the EncapsulatedContentInfo OID).  Maybe that’s fine, but by omitting the
version field, specifying only one compression algorithm, and having only 5 content
types you are saying there’s no intent to ever add other compression values or
content types.  I.e., it's one and done?  To make any changes as specified you’re
going to have to get a new content type OID.  Might be good to just state that up
front if that’s the case.  I’m pretty sure nobody is investing any money in new MHS
content types.

Actually that makes me wonder, why isn’t the only content type defined P1?  Isn’t P1
MTA-MTA and P3 and P7 MTA-UA?

s3.2: You should probably point to the zlib long form OID in these registries for
the long form:
https://www.iana.org/assignments/smi-numbers/smi-numbers.xhtml#security-smime-3

s4.1: There’s a TBC - to be covered?

s6: Is there an expert pool or is it just one person for the registry’s DE?

s7: Is still TBD :)


Reference nits:

Refer to 2015 ASN.1?

I can’t really find ACP142 anywhere.   Now I’m not sure that’s really a show stopped
because like anybody building this is just building it for the fun of it.  They’ve
been given it.  But, maybe I’m just not searching for it correctly?   I also get the
impression that somebody does have it because there are all kinds of wireshark
tools.

Because there’s two version of ACP 142.  I think that somewhere up front you should
use ACP 142(A) so that those in the know know it’s not the ’01 version.

Editorial nits:

s3.1: r/CR LF)/CR LF).
s3.1: r/CRLF.CRLF/CRLF.  CRLF
s3.1: r/Example of a BSMTP-like payload/
An example of BSMTP-like payload follows

===============

>> On 11/10/17 08:19, Barry Leiba wrote:
>>> Hi, Nevil.  Sorry I couldn't get to this until today.
>>>
>>> Alexey does some work with military contract that this appears to
>>> relate to, and we decided some time ago that most of the specific
>>> requirements that come from that don't really belong in the IETF
>>> stream.  So it seems perfect for the Independent stream, and I see no
>>> problem with the protocol description relative to that.
>>>
>>> The only issue I have is in the IANA Considerations, where he asks
>>> IANA to define a registry with the Specification Required policy.
>>> First, quotation of the policy needs to be accompanied by a normative
>>> reference to RFC 8126, which is missing.
>>>
>>> But second, "Expert Review" and "Specification Required" mean that the
>>> IESG has to appoint and manage a designated expert, and we decided
>>> some time ago that it's not appropriate for the Independent stream to
>>> commit the IESG to that, and that Independent stream documents
>>> shouldn't use those registration policies.
>>>
>>> What we decided was that it would be appropriate to cite the policy
>>> but to explicitly specify a different mechanism for expert review.
>>> So, perhaps "Specification Required, but without designated-expert
>>> review of the specification," or "Specification Required, but
>>> <organization X> appoints and manages the designated expert."
>>>
>>> Barry
Back