Multiple Attachments for Electronic Data Interchange - Internet Integration (EDIINT)
RFC 6362

Note: This ballot was opened for revision 14 and is now closed.

(Alexey Melnikov) Yes

Comment (2011-03-12 for -)
No email
send info
Should this document be published with "no IETF consensus" boilerplate?

(Pete Resnick) Yes

Comment (2011-05-24 for -)
No email
send info
This is an individual submission of an Informational document I picked up from Alexey, so I don't know the full history. Sean's discuss (the only one) has been cleared, so I could approve it, but since half of the IESG hasn't entered a position, I'd like to double-check and have people give it a gander before sending it on its merry way. 

(Jari Arkko) No Objection

(Ron Bonica) No Objection

(Stewart Bryant) No Objection

Comment (2011-03-16 for -)
No email
send info
There are a number of id-nits that need be fixed before the document considered ready for publication (IANA section and RFC2119 language). Also the editor should confirm that all of the lower case "should" instances are correctly set.

(Gonzalo Camarillo) No Objection

(Wesley Eddy) No Objection

(Adrian Farrel) No Objection

(Stephen Farrell) No Objection

Comment (2011-05-30 for -)
No email
send info
Even though this has enough positions to go ahead, Pete 
asked if newbies like me were ok with that, so since I'd not 
seen this before, I took a look. I've no problem if these are 
ignored really, but fwiw:

(1) The draft says that people "began" doing stuff, which is
fine, but would be even better with some references to that
(if some exist) so the reader could understand better.

(2) s/this body is covered/this body are covered/

(3) It says the attachments "should" be inter-related - is that
meant to be a 2119 SHOULD? I'm also unclear as to what 
inter-related means, but I guess that's really a higher
layer issue (in which case do you really need to impose
the constraint at this level?). If that was a 2119 SHOULD
then under which conditions is it ok to ignore the 
rule? (maybe easiest is s/should/ought/ just to avoid 
potential 2119 confusion)

(4) I think 2.3 says that for an encrypted message the MIC
is calculated over the plaintext but is sent outside the
encryption. If so, that's less common than also encrypting
the MIC and is usually specifically justified, but maybe 
I'm misreading it (and I didn't go read the references to
check sorry;-)

(5) Section 4 mentions "the three EDI-INT transport 
standards" but doesn't include the references at that
point - I think it'd be good to repeat those for clarity.

(David Harrington) No Objection

(Russ Housley) No Objection

Comment (2011-03-16 for -)
No email
send info
  In the Gen-ART Review by Pete McCann on 15-Mar-2011, a concern is
  raised.  Please consider it:

  There is a space in the declaration of boundary=" INNER-BOUNDARY";
  in the example in section 3.  I am not sure whether this was
  intentional or whether it will mess up a standard MIME parser, but
  you may want to remove it.

(Peter Saint-Andre) No Objection

(Robert Sparks) No Objection

(Sean Turner) (was Discuss) No Objection

Comment (2011-03-16)
No email
send info
Sec 2.3 says: 

   If the expected MIC value differs from the calculated MIC value, all
   attachments MUST be considered invalid and retransmitted.


Isn't telling the initiator that they didn't match and asking for the retransmission missing?