Session Date/Time: 23 Apr 2026 14:00
Debra Petta: All right. It is- it is the top of the hour. Do we want to wait a few minutes, because there's only like five people in here plus the two chairs? Or do we just go ahead?
Bojidar Ivanov: Debra, I suggest we- we go ahead, as long as the chairs are here.
Debra Petta: Okay.
Bojidar Ivanov: Because, you know, you don't really know if people will be coming and- we- we spent, you know, a significant time for making sure that people are all available, the people that are participating, by doing a specific doodle which, to my knowledge, I haven't seen done in any IETF meeting before. So, if people don't show up then, you know, I'm sorry.
Debra Petta: Okay. That's fine. That's fine. Um. So... All right, then let's move to- do you want- I can- let's move to slide 34. Let me get to that. Or... Yeah, Joe, please do the formal stuff, so...
Joe Mandel: Okay. Go ahead and- just let me know. Let's- and we want to start at slide 34. I'll give a- a brief um summary and then we can go from there.
Debra Petta: Sorry about that. Took me a minute to figure out how to share.
Joe Mandel: No problem.
Debra Petta: No problem.
Joe Mandel: All right. This is the Note Well. It um covers IETF um policies on conduct, privacy, uh and IPR. Uh take a moment to look over it when you have a chance. Uh meeting tips um make sure your audio and video's off unless you're presenting. Um please use a headset if you can and state your name when you enter the queue, so we uh know who's providing feedback. Uh here are some links for Notepad and the meeting. If somebody um go into Notepad and uh help us take notes, minutes, that'd be great. Agenda, um we covered the Note Well and agenda and then it's um Debra with her presentation. So, if there's no questions, we'll move on to that.
Debra Petta: Excellent. All right. Thank you. We- this is part two of our presentation for the RFC 4130 modernization um documentation, the RFC 4130bis. Sessa - rfc4130bis Um in our- our first part, we only got through- the slide deck I think has 60 slides and we only got through 34 of them. Um we did stop mid-stream- or mid-way through a section and that section was our feature documentation section. Um the first thing I think I talked about in there was that our feature documentation is- is from the features that have come from our user community. And I started and said specifically that we would be working with- um or we've already discussed um CEM, which is Certificate Exchange Messaging, which is uh an automated certificate exchange feature between trading partners and it helps with um certificate renewal without manual intervention. Uh so we've discussed that and then we moved on to AS2 Reliability, which is used for checkpoint and resuming of inter- interrupted transfers. This is particularly useful for unreliable networks. Um then we- we got on and we should be now on slide 34, which is AS2 Restart feature. Um so I think you are on slide 36, yes. So, if we get to AS2 Restart and we'll start from there. So, AS2 Restart is documented in section 5.5 as a new capability, however, it is another feature that's been widely implemented by multiple vendors. The purpose is to resume interrupted message transmission from the last point of failure. It provides a large file transmission and re-transmission support. The mechanism it uses is- using the HTTP range headers for partial content. The sender includes the byte range of a successful transmission and the receiver requests the remaining bytes. The transfer resumes from where it last failed. The most common use case is for large file transfers that fail mid-transmission due to network interruptions or timeouts. This is an optional feature. It references the internet draft, draft-harding-as2-restart. Um multiple vendors have already implemented this feature. This is- this is different from AS2 Reliability. Restart is- is about resuming a single interrupted transfer, Reliability is about the broader checkpoint and retry framework. Um next slide, please. Um next is Compression Support. RFC 4130 had no compression guidance at all. RFC 4130bis explicitly documents compression support. The compression implementation uses ZLIB compression referenced in RFCs 1950 and 1951. The content encoding is either GZIP or Deflate. This is an optional feature, it is negotiated between partners, it provides significant bandwidth savings for large EDI or text files. Um based on some recent discussions I've seen on the list, compression is always applied before encryption, however, implementations may apply compression before or after the signature. That is you can either sign and then compress or compress and then sign. Um conform- conformant implementations should be able to compress either- decompress either way. Um note that the- the message integrity check always applies to the signed portion of the message and includes the inner headers of the signature. I can provide more examples um when- about this and we can discuss this further on the list. Um benefits of compression- reduces transmission time, lowers the bandwidth costs and is especially valuable for large transaction sets like purchase orders, invoices and shipping manifests. Um multiple vendors have implemented this for years, we're just finally documenting it in the specification. Next slide, please. Um file name preservation has been widely requested by the user community. In the original RFC 4130, the content-disposition header was just briefly mentioned, file name handling was unclear and there was no standard way to associate a transmitted payload with a file name. Uh so we use the content-disposition um header for that and include the file name as a parameter within that header. Um so- so in the example it would um having a file name invoice1234.edi. The file name parameter is recommended for business documents. Um it uses RFC 2231 character encoding for non-ASCII file names. Uh the recommendation is that um that the path information must be stripped for security, um never include the path as part of the file name. Uh the length limits, practical guidance is no more than 255 characters. Um multiple attachment handling is clarified and we will discuss that on the next slide. Um file name preservation helps with automated processing and document routing. Users want their invoice 12345 to arrive with the exact file name not message.dat or some system generated file name. Next slide, please. Support for multiple attachments is now explicitly documented. Multiple attachments use multipart/related um for bundling related documents together. It was initially requested by the petroleum industry for associating images like schematics with other information but it can be used within any supply chain. A business use case for this can include an invoice plus supporting documents like packing slips, shipping notices and so forth. The content-id headers are used for references between multiple parts. As referenced in the previous slide, multiple attachments can also include file name preservation. The content-disposition file name parameter is added to each- each part of the attachment. This is critical for automated document routing. As with file name preservation character encoding guidance is provided as per RFC 2231. All of this is marked as optional. We're enhancing interoperability by documenting what vendors have already implemented. We are not changing the core requirements. Next slide, please. Um we're at a discussion point because we've- we've finished through this section. Um are we documenting the right features here? Um so we've included CEM, um AS2 Reliability, AS2 Restart, um and multiple attachments. Is there anything that's widely implemented in AS2 that we're missing? Um does anybody else have any comments or questions at this point? Go ahead.
Bojidar Ivanov: It's- it's not related exactly to this question but to content on the previous slide, uh the size and the restart. Uh so what I've seen implemented is many implementations have a limit of 50 megabytes per message. Um so I'm not sure how practical it is to transfer large files and whether it's actually practical to do restart for resume for a 50 megabyte transfer.
Debra Petta: Where- where are you seeing that requirement of 50 megabytes because we have- even within the Drummond interoperability testing, we've- we've been able to- to do larger um transfers or re-transmissions. Um 50 megabytes is only what we've tested within our- our initial but there- we do test um in the gigabyte range.
Bojidar Ivanov: Okay. All right. If- if that's the case and we see out in the wild larger transfers then it- it may make sense, yeah. Um one last comment about the- the size of the file names. Um 255 um I'm assuming that's the original file name length not the header length, right?
Debra Petta: That- that would be the content of a file name. And- and I think that 255 is probably too large but we had to say something um we had to put a maximum on it. If we want to go lower instead of saying 255 we can go um 128.
Bojidar Ivanov: No- that's good. I mean it's widely adopted limit so it's good.
Debra Petta: All right. Okay. Anybody else have any other questions or comments? All right. Um let's move on then. We are um then on to okay, section 8 um moving on to MDN updates, message disposition notifications. Um section 8 has four key changes. Um the first, we've updated to RFC 8098 which obsoletes RFC 3798. We've added new disposition modifiers and clarified requirements. Um the second is we've enhanced disposition modifier extensions. We'll cover these in detail on the next slide. Um number three, we've clarified synchronous versus asynchronous MDN handling. For synchronous, the MDN is returned in the HTTP response body. For asynchronous, the MDN is sent with- with a separate POST to the receipt-delivery-option URL. Um the 204 No Content response is now the preferred response for asynchronous acknowledgments. And for number four, we've included the receipt-delivery-option requirements. If this header is present, the URL must be HTTPS. Authentication requirements are specified. To protect the MDN and header content you should not use insecure HTTP for asynchronous MDN delivery. Next slide, please. Okay. So RFC 4130bis adds detailed- um was a question? Do we- do we want to answer questions as we're going or do you want me to hold? Marc, did you- did you have a question?
Marc Blanchet: Um I guess it's really up to you uh chair at- on uh when you want then- I was kind of more registering my own question but uh let- given that I interrupted you I guess we'll- we'll-
Debra Petta: Well if you- if you want to back up did you have a question from the previous slide?
Marc Blanchet: Yes. Yes. Okay. Um so uh there's a- um I don't have the current policy uh you know in terms of RFC number but uh IETF has- uh since Snowdon has uh required everything to be over HTTPS. I know that um you know AS2 has been run over HTTP uh given that- that AS2 itself is encrypted but um I'm just warning the working group that we may not have a strong uh support in the ISG when we do uh at the publication uh request time uh if we support HTTP uh not- you know if we still support HTTP. Um moreover um I would also add my own kind of um... not opinion but subjective comment which is uh you know what is the problem with using HTTPS which is so standard now? But so I leave it to you but um I'm just saying you know we may have a problem with HTTP not uh not with TLS uh later on.
Debra Petta: I am- I am agreeing with you. The- the testing that we've done within Drummond group we are moving away from using HTTP. HTTP is just considered, air quotes, legacy and we are moving more to a- a fully um secure HTTPS for- for most of our- our testing now. Um we do handle those that are still um that still support HTTP. Um and most of it's just for our testing but I think out in the wild and- and I don't know for certain but I think in the wild most implementations are using HTTPS just because it is more secure. I know that that's adding encryption as an additional level. Um so it's HTTPS but then encrypting the payload as well. And- um but I think that that's what um vendors are using and um that's what they want.
Marc Blanchet: Uh you know um I think what Drummond does in terms of conformance is great and you know fantastic but um you know um what Drummond does doesn't mean that- that should be part of the spec, right? It's a diff- just a completely different, you know, topic, right? Um so- I agree. Yeah. So what we're trying to do here is- is make a spec which, you know, is agreeable, you know, in- within the community and IETF ISG and all that stuff so. And often good or bad but uh at least at the IETF level um we don't touch much of the or we're not trying to do things related to conformance testing, right? It's kind of a- it's kind of a side effect of the spec not- not, you know, the- the main topic. So it gives business to you guys but um you know compared to other um SDOs that conformance is actually integrated in the process. We are- we're not doing this. So... um well- well that's something we should maybe have a- a- um Joe, I'm thinking maybe later we could ask the group here see what's- what's the- um what's the level of support of only saying, you know, HTTPS um because it might be just a no-brainer and that would facilitate a lot um later on for publication requests.
Debra Petta: I believe that it is a no-brainer and- and when I say that it- it's not Drummond Group stating that it- you must use HTTPS. It's Drummond Group hearing from the user community that that's what they want and so that's what we test just because that's what they want and that's what's used as far as we know out in- in the broader community. Um go ahead, Bojidar.
Bojidar Ivanov: If we want to drop HTTP from the new spec I- I won't object. It's common sense HTTPS now.
Debra Petta: Okay. Um do we- do we want to be backward compatible with those who don't support it or do we just say that from here out we just don't support HTTP anymore?
Bojidar Ivanov: To me that's again to the other threat that we have. Dropping it doesn't mean that implementations will not support it. The new spec will not support it but implementations can support HTTP to interop with older clients.
Debra Petta: Okay.
Marc Blanchet: I agree with that point of view.
Debra Petta: All right. We'll have to note that then. Um I just had one comment like, you know, um maybe yeah it makes sense to like have that as a- part of the implementation but not part of the spec but I think what typically happens if it's not part of the spec it gets taken out of the implementation also and because we have a lot of these customers and I mean we are also trying to move forward and go to all the encrypted, you know, protocols and everything that's all fine and planned but in reality we still have some of the older customers who are using that um so we would expect the other customers or the other AS2 implementers to also support that um and if you take it out from the standard then it means that some folks might remove it um that's all I'm saying. I mean...
Debra Petta: So the- the whole idea is that we remain backward compatible with those who still support it. However, for newer implementations, the recommendation is that we move to HTTPS. Is that what we're saying?
Marc Blanchet: Agree. Yeah. Exactly. Well, um a slightly different perspective is that for example the IETF said uh for now on uh HTTPS is the only transport for HTTP and, you know, for now on, you know, some crypto algorithms are um not allowed for in our specs, right? So that's the point of view. Um what is in the wild is up to, you know, the wild, right? So um so therefore if people still use HTTP that's not the per- you know that's- the purview of the IETF. IETF doesn't have any police or anything, right? So and- and again if we're saying HTTP you uh only or not only but if we allow HTTP in the spec uh you know you'll- you'll see massive number of comments from the ISG later so.
Debra Petta: Okay. All right. Anybody else have any other comments? Okay. Then let's move on to slide where- where was I? Slide- did we get through the um slide 42 what- okay so we're at Enhanced Modifier?
Joe Mandel: Yes. I think we're on 41.
Debra Petta: Okay. All right. I see it. Thank you. Um so RFC 4130bis adds detailed disposition modifiers in sections 8.4.3 and 8.5.4. We've expanded the error conditions list to include these optional dispositions. These are a collection of modifiers that are already in use in production environments. Um the authentication-failed was originally specified in- in 4130. Um decompression-failed is- is a new modifier and it's related to the compression support. Decryption-failed is from the original and then the next two, duplicate-file-name and illegal-file-name, have stemmed from file name preservation with MDN support. This came from the Financial Services Technical Consortium, fstc.org, and it handles error scenarios for instance when a file name is already in use and an overwrite may occur or the file name has um is- is malformed. So- so the duplicate-file-name and illegal-file-name are new for those reasons. Um there's the insufficient-message-security and this is new when the expected signing and/or encryption has- has not been applied as expected. Um integrity-check-failed is original. Um the invalid-message-id is new. We found that- that users are using this now. Um un- unexpected-processing-error is original and unknown-trading-relationship is new. What I've been trying to do is just collect all the modifiers that we've seen in use in the field so that they're documented in one place and users are and implementers know that these are are valid modifiers that can be used within products. Um there's also warning-conditions and we really haven't specified any but this is where you would put warning conditions. The purpose of this is for error reporting and troubleshooting. Partners can diagnose specific failure points instead of getting a generic error response. Um an example of just failed is if you got a decompression-failed, which could tell you exactly where the problem occurred. And I see hands raised so why don't we go ahead to those questions and then um we can move on to the next slide. Um Asgar, go ahead.
Asger Smidt: Yeah, Asger Smidt. Uh yeah like I commented on the mailing list as well. I've never seen unknown-trading-relationship used anywhere. You commented that you had.
Debra Petta: Yes I have.
Asger Smidt: But- but the one- but the one I have seen used many, many places is unknown-trading-partner. What do we do with multiple different versions of the same error? Do we just add them all to the list or how do we plan on- on doing this?
Debra Petta: What do you recommend? Because I have seen unknown-trading-relationship.
Asger Smidt: I- I don't know but I know that- that specifying only unknown-trading-relationship is going to sort of cut off a lot of existing implementations because- because I have seen many that use unknown-trading-partner.
Debra Petta: Well I could add it to the list as- as an additional-
Marc Blanchet: Mark here. Um this is also related to the comment I made uh on the mailing list of my review. Um and actually I think that answers the question is- all those should be put in a IANA registry, right? So that um uh if new ones are defined in the field as we go then you don't need to change the RFC but you just need to change to add something to the IANA registry. Then you have the RFCs that says please go to the IANA registry for the latest list of for in this case error conditions or warnings. So any- any kind of enumeration in typical IETF specs often go into IANA registry. And what you do is you- for adding a new- a new enum value then you define a policy. Uh and that's the purpose of us that says uh if- if you want a new token, what do you need to do? Do you need to write a spec that describes the token or do you want to have a review from experts? Um and- so that kind of policy is defined in the RFC so that IANA will as a custodian will actually act based on the policy. So if someone comes in and says I want to add a new error condition to that registry then IANA will look at the policy and say, ah okay, the policy says I need a spec, please provide me the spec, okay? Or if the IANA policy says expert review, then there would have been experts already assigned for that registry and then the expert will- will review the request and- and tell IANA that's fine or this is completely broken or things like that. So I think we should have IANA- there's a few instances in this document about enums and having a IANA registry will just solve the problem that you had over time which is new conditions were added and people defined, you know, variations of them and then you get interop problems. So uh I would highly suggest that we consider IANA registries for those.
Debra Petta: Okay. If you can just point me to how to do that, I can set that up.
Marc Blanchet: Sure.
Debra Petta: Okay. And- and I think as a group maybe we decide on- on any others that need to be added and we can just start adding those to the list. So we- I know that we've seen the unknown-trading-relationship so it could be either unknown-trading-relationship or unknown-trading-partner as recommended by Asgar. Okay? All right. Thank you. Let's- let's move on to the next slide. Um well the next slide is actually discussion points for- for MDNs. um and maybe we've gotten to all of these discussions as we've talked about it so far. Um so the modifiers, we're saying that we- we want to collect the list and add those to IANA and then for the receipt-delivery-options we're going to require um we're going to require HTTPS um moving forward in the specification. So that would include for both the- the initial transport and the asynchronous MDN that's returned. Um does anybody else have any other comments about- about anything that we've discussed in this section? Okay. Let's move on to um the next slide. This is Security- Security um requirements and discussion of HTTPS and TLS. Um this is a new section that we've included in RFC 4130bis. Um next slide, please. Section 10.1 is completely new in RFC 4130bis. In RFC 4130, HTTPS was optional and was mentioned only brief- briefly in the security consideration section. In RFC 4130bis, HTTPS is recommended for new implementations. And we can make that even stronger to required if you- if you think that that's um that's better. Um the rationale for this is it prevents the man-in-the-middle attacks on AS2 message headers, protects all identifying transport headers, it's required for secure asynchronous MDN delivery and it's recommended as an industry best practice for 2025 and beyond. Um for backward compatibility, HTTP is still supported for legacy partners. We're encouraging gradual migration, not forcing an immediate cutover. Um TLS requirements stated in section 10.1, TLS 1.2 must be supported. This is the minim- minimum. TLS 1.3 should be supported, this is the modern standard. TLS 1.1 and below must not be used, these have known vulnerabilities.
Bojidar Ivanov: Debra, I would change TLS 1.3 to must.
Debra Petta: Must?
Bojidar Ivanov: Yeah.
Debra Petta: Okay. Agree?
Bojidar Ivanov: Agree.
Debra Petta: Okay. I will- I will make note and and after this I think we'll probably have to um include a- or I'll- I'll do a summary after this and- and say the things that we were changing. But yes. So this is changed then to must. Okay. Next slide, please.
Marc Blanchet: Um Debra just for- for your information I'm- I'm taking notes uh you know for the meeting itself as I did last time and I would love to have other people either contribute or at least review the notes uh so um you know if it should be on somewhere on your screen there should be a button for look at the note-taking function.
Debra Petta: Okay. I've- I've got a- a different screen in front of me than the one that I have here so I was just writing down notes as we go. But if somebody else is taking notes that'd be very helpful for me so that after we're done here I have a list of things so that we can go back into the spec and make those changes and I don't miss anything. Um and I'm sure if- if I miss anything I'm sure you guys will let me know. Um okay so moving on to the next section or the next slide. This is just a- a visual of what I just said and we'll be changing it then that anything below TLS 1.1 and below you must not use. Um and we're saying in TL- TLS 1.2, are we saying must support on TLS 1.2 and TLS 1.3 or a may on 1.2 and 1.3 is a must?
Marc Blanchet: I suggest you're essentially silent to everything and just say must TLS 1.3 and forget about everything else.
Debra Petta: Okay, so- so no 1.2 going- no that's also not supported?
Marc Blanchet: Uh well it's the same discussion we had, right? If people do TLS 1.2 there is no IETF police that will, you know, go there, right? But the spec itself has to be under modern security standards and modern standards and that's TLS 1.3 that's it.
Debra Petta: Okay.
Bojidar Ivanov: You- you can keep it and add may support 1.2 but TLS 1.3 is must.
Debra Petta: Okay. Got it. Thank you. Amir?
Aamir Shaikh: So um yeah just one thing so what would- what happens if it's not supported then do- does that break the compatibility because we- I think we do have some- this is the implementation, right? So if- if it says must support then it's not backward compa- I mean I understand 1.2 and 3 are weak um they- they should be getting off of but um maybe could we do it like six months down the road or something?
Debra Petta: I would- I would suggest a gradual migration as well. Um backward compatibility is- is utmost is being able to support backward but we're saying moving forward new implementations will support HTTPS but may support 1.2. Um are you saying go- going back even further with 1.1 that must not be used?
Aamir Shaikh: No- I'm not saying that. I'm just saying that TLS 1.3 should support seems to be okay to me. If you say must support that means that um they'll be forced to do the 1.3 um and they might not do it right now.
Bojidar Ivanov: That's- that's the idea actually. If any implementation wants to claim support of the new RFC, they must support the latest and greatest security measures. For- for transition period from the old RFC to the new RFC, this is going to take years, it's not going to happen in a month. Um so I'm sure that implementations will support both but if you want to claim I am 1.3 AS2 1.3 compatible, then I must support TLS 1.3.
Marc Blanchet: Again, that's- um there's a difference between uh the spec and the implementation, right? So I agree with what Bojidar just said which is uh to be conformant with this spec you must support TLS 1.3. Therefore someone could send you something in- over TLS 1.3 and you should be able to decode it or decrypt it, you know, receive it, right? Um the fact that your implementation may have all kinds of bells and whistles, that's another story. And then to your point Debra about uh transition, then that's kind of another topic, right? That's- it could be a- a set of- of industry people that- um that- you know sit together and say we'll do this uh for January 1st, 2027 and, you know, we do that and that's another story. That's not the IETF purpose.
Aamir Shaikh: No the point is that I'm saying on the right column you have the status which says required or recommended, right? So once you put must support on TLS 1.3 then it becomes required. So um a lot of the older implementations they will be out of compliance.
Bojidar Ivanov: Yes. Older implementations are not compliant with the new RFC.
Aamir Shaikh: Right, but then- exactly. Yeah you would not be able to get the Drummond certification that's what I'm saying.
Debra Petta: Well that would be that if we were testing the- the- this new specification right out of the gate which we'll have to- as we're testing this we'll have to roll into it as a- as a group and decide how- how we want to implement this new specification. It'll be a- I still believe that we have to remain backward compatible for a period of time.
Aamir Shaikh: Yeah, I feel the same um yeah. So I mean can we keep it as- as it is right now like should support and recommended versus a must support and required.
Bojidar Ivanov: I- I have very strong opinion that it should be must uh because I- I differentiate between implementation and spec. Um the implementations will need to support old other partners that are not compliant with the new but anybody claiming they're compliant with the new, they must support the latest and greatest.
Marc Blanchet: Agree with that point of view. And again it's similar to HTTP, which is if- if we go into a- publication request and say uh you know TLS 1.3 is recommended and TLS 1.2 is required um you'll get the security AD will say, you know, I'm sorry. That won't pass. So...
Aamir Shaikh: Okay um let's- we'll deal with it then.
Murali Panidepu: So Debra this is Murali from Axway. Um so would we meant for 1.1 do we mention like, you know, um something like backward compatible something like that?
Debra Petta: Are you saying for TLS 1.1?
Murali Panidepu: Yes.
Debra Petta: I know it says must not but that would be for support of this spec. We- what you're saying then is you support RFC 4130 not 4130bis. So as we move into the new- what we're saying is as we move into the new specification then- then we would be removing um support in- in going backward. And that- that really wasn't my intention when we did this. I wanted to still maintain backward compatibility for a period of time. Um and and I think what we're saying is that this is a rollout and it will take years to get there. I think we just need to as a group decide how we want to migrate to the new specification and- and how we want to handle um older implementations.
Murali Panidepu: Okay. Um I think- I think for many major providers there is an end date specified for many of these large organizations uh for TLS 1.1 so do we also specify an end date something like that?
Marc Blanchet: Again, that's not the purpose of the IETF. That's not the purview of the IETF. It's- it could be an industry, you know, consortium that says that, right? Um so again here we're- we're defining a specification which is um on the, you know, a current modern specification and we may as I uh wrote in- in um on the mailing list, we may have an annex non-normative annex that says if you support both um, you know, versions, then you may want to do this or that um but you don't have to rewrite what it's, you know, specified in the first version, right? You don't have to say support sha1 or not and you don't go there. You just say for an implementation that support both, in- you know do this or that in case of this or that and that's it. And that's non-normative. Or uh what also has been done in the IETF is a separate document which is informational that says uh to help transitioning uh, you know, you should do this or that or you know whatever and that's kind of a- another spec, right? But the main spec remains clear, clean, unambiguous and easy for implementers and certifiers and whoever else to define, you know, I'm supporting this, right? Um that make it clear. Right now the- I mean the spec is fantastic, right? Debra, you- you're very good writer but the problem is that, you know, the different versions and what needs to be speci- you know supported and not is all over the place and it- it and actually may not actually succeed in- in publication request because if we say, you know, TLS 1.2, you know- or HTTP or sha1 may uh because you know uh in the security point of view if you say may, that means that- that people will- will be able and to use it for the new spec. Therefore they will be conformant to a spec that says uh, you know, may sha1 therefore, you know, this is completely insecure so. Anyway.
Debra Petta: Okay.
Marc Blanchet: Uh and here I'm really trying to help here. I'm just, you know, I'm not an implementer. I've used that- that AS2 products before and still but uh you know, I'm just trying to help here.
Debra Petta: Okay.
Bojidar Ivanov: And- and one last comment. Debra, Drummond is the place where the industry meets. So if you decide that you run campaign to certify 1.3 implementations and you decide and communicate date when you will stop certifying older implementations, this will be the driver and the timelines for the whole industry. And people participate, so there is a forum for that discussion to happen.
Debra Petta: Well I- I would never myself just, you know, drop the hammer and say this is when we'll do it. I think that we need- need to get input from our AS2 community and determine what works for everybody and- and how you want to move forward. Um so- we can discuss that once we've- have the spec written we can decide how we want to transition from- from the old spec to the new spec. Um Asgar, I see that your- you've had your hand raised for a while. Do you have a comment or a question?
Asger Smidt: Uh yes. Uh it- it seemed to devolve into a free-for-all. I'm the only one actually using the queue. Uh but I am a bit concerned that we are redefining what "must not" means. Because what I'm hearing is that if you want to be certified, you have to uphold anything that says "must", but if you support anything that says "must not" for backwards compatibility reasons, that's perfectly fine. Which means that "must not" does not mean the opposite of "must" anymore. Those are two completely unrelated terms. In- essentially, whenever it says "must not", you can safely ignore that. Doesn't matter.
Debra Petta: I and- and I think what we're- we're trying to do is still remain backward compatible, at- at least that- that was my intention with writing the spec was being able to support other systems in the wild so that when you came in and picked up the spec, you- you could- you could still implement this spec and use backward compatibility by using a version to say that if somebody has a version that's still 1.2, if you implement 1.1 and both- both partners support 1.1, then you would use the new implementation. But if one still supports 1.2 or lower, then you can still be backward compatible. Um unless there's a different way that we could do it, but- but that was my reasoning or my thought process for writing the spec is being able to transition by using a version or something like that.
Asger Smidt: But in that case, I guess I just don't understand what "must not" means. What- what is the point of including it? Essentially I'm saying if- if- if you're allowed to use all these things for backwards compatibility purposes, why are they in the spec at all?
Debra Petta: Does anybody still use TLS 1.1? Um I- I think I heard that-
Asger Smidt: Let- let me be clear. I am not advocating for the use of TLS 1.1. I'm speaking generally. Anything that the spec says "must", if it really doesn't matter if you do it or not, then we might as well remove it from the spec.
Bojidar Ivanov: Asgar, your logic is sound. Uh my interpretation here is that if you're talking to an- AS2 1.3 implementation, you must not use the weaker protocols. But it's- you can simply remove it, right?
Asger Smidt: Yes, but unfortunately it's quite often impossible to know what AS2 version you're talking to until you have actually exchanged messages in both directions.
Debra Petta: I think we- we did talk about that last time, that we needed some way to before you- you transmit a message being able to find out the capabilities of the other- of the other trading partner. Um either I think there was a comment about using well-known or um AS2 Get or some other way to know the trading partner's capabilities um before you try one. Or you- you try one and if it fails or you just do a some sort of unknown or some sort of message transmission just to get those headers so that you know and then you can move forward from there. Or you talk out-of-band and know that- what the partner um handles.
Asger Smidt: Yes, but the partner often doesn't know.
Debra Petta: Right. Um-
Bojidar Ivanov: We- we can't solve that problem in the RFC if the partner doesn't know.
Debra Petta: Okay. Mark? I think a lot of this conversation we're just going to have to table to the group for discussion. Um unless Mark, do you have a comment? I- I think what we- we do, we would just include this as a- a comment going forward and we can have a greater discussion in- in the list because I don't even know if everybody on this list- um or in this call is on the list and has um feelings about it. So- um what we can do is just get a- a list of all the things that we've discussed and- and talk about it in the mailing list. Is that okay? Because I- I know that we're not going to be able to solve this today.
Bojidar Ivanov: Yeah. Um I'm personally okay, Debra. Um and I see we have, what, 13 more slides. So...
Debra Petta: Yes. So- we- I want to make sure we get through this today and then we can have a- a greater conversation. Yeah. On that note, I think we should try and use the mailing list more. It- it seems like right before a meeting there's a flurry of activity and- and then nothing in between.
Debra Petta: Okay. All right. Let's move on to the next slide. Um- um this is- is this slide 3- 46? 46. Okay.
Joe Mandel: It is.
Debra Petta: Okay. All right. I see it. Thank you. Um so section 9 um talks about certificate requirements and they've been substantially enhanced. We- we've made the key lengths a minimum for RSA of 2048 bits, 3072 or greater is recommended. For ECDSA P-256 is a minimum and P-384 or greater is recommended. Um certificate types we've- we've made an important distinction. We have TLS certificates, they're used for the transport layer, that is the HTTPS security. And then there's S/MIME certificates, those are used for AS2 message signing and encryption. These should be different certificates. They have different purposes, different risk profiles and different operational lifetimes. Um we've added the- the allowing of self-signed TLS certificates, this is new in section 9.1. We state that it's acceptable if they use a subject alternative name extension, the SAN extension. Um the SAN must contain the hostname or- and/or a IP address. This makes it useful for private trading partner networks and test environments. Um the fourth is as part- as part of the certificate validation you must validate the certificate chain back to the trusted root. Um you must check the certificate revocation status and must verify the hostname matches the certificate. Um certificate exchange messaging, uh reference the draft-metters-certificate-exchange internet draft for automated certificate exchange. It's becoming increasingly important, more on this on the next slide. Um so move on to the next slide, please. Um so- this um the TLS certificate lifetime trend. Um this is a critical operational issue that we see affecting every AS2 implementation. As an industry trend, DigiCert and other certificate authorities are moving to a 47-day maximum lifetime for TLS certificates by 2029. Um this is driven by um security best practices, shorter certificate lifetimes reduce the exposure window if a private key is compromised. Um this is a distinction that's being made in RFC 4130bis. For- for TLS certificates, the 47-day um timeline applies here. These are used for HTTPS transport security. S/MIME certificates would have a one- to two-year recommended lifetime, these are used for AS2 message signing and encryption. They have a different risk profile, longer lifetimes are acceptable because these are used for business operations not transport security. Um there is however an operational impact for the TLS certificates. The 47-day TLS um renewal cycles will require automation. Manual certificate management becomes completely impractical. So CEM becomes critical, Certificate Exchange Messaging with the um internet draft provides automated certificate exchange. Um this was a nice-to-have feature with the 47-day renewals, it's becoming operational- um operational- essentially operationally essential. Um so my recommendation is we should strengthen CEM from "may" to "should". Um "should" meaning that- that you really should implement this and if you don't you- you need a good operational reason why you're not. Um it signals the importance without making it mandatory, which would break backward compatibility. Go ahead Bojidar.
Bojidar Ivanov: Uh- for TLS I- I don't think this is needed because you trust the root certificate and the certificate of the remote system can change every day. You don't need to change anything on the client connecting to it. So this I- I don't think this is needed for TLS certificates.
Debra Petta: Sometimes though we- we are seeing and- and I know from my experience that there are products out there that require that you always change the root. And if the root certificate changes then the entire chain is compromised.
Bojidar Ivanov: If roots rotate every 47 days, I- I agree, but currently they're issued for 10 years, most public CAs.
Debra Petta: Uh there's- there's a new industry trend that is just coming out that says that by 2029 the root certificates are going to change every 47 days. That's- that's okay. That's what we're- that's what I've been told. That- that's what we're seeing. So- so that means that we need some sort of automated way to change that root certificate with- automatically instead of having it- um every- every time.
Bojidar Ivanov: Do- do we need that really in the AS2 protocol?
Debra Petta: That- that's a question for IETF because I've been- been informed that DigiCert and other certificate authorities are moving to 47-day maximum lifetime. So if- if a CA certificate is DigiCert and the CA certificate is used by AS2, then that certificate is only going to have a lifetime of 47 days. Um maybe we need to bring this to the group as a conversation as well. Because what we're seeing is that- that this will affect AS2. Maybe- maybe it shouldn't affect AS2 and and- I can- we can discuss this as a group but- but that was my- this is what I've been told that- that this is going to affect AS2. Does anybody else have any other comments on that? I know Murali, I know that you're- you're aware of this 47-day industry trend for- for CA certificates. Is that something that- we want to bring up here or- Amir?
Aamir Shaikh: Yeah I had a thought there um go ahead please.
Murali Panidepu: Yeah sorry I mean so it's more about like you know so we were hoping that you know the trend industry trend is going to change uh especially for we- we need to have more clarity on the root certificate especially so other than that uh you know I mean lot of customers are showing to adopt the CEM.
Aamir Shaikh: Yeah I have also heard about this and uh I think the date like you mentioned 2029 uh yeah that- that seems right uh yes. Not sure exact yeah that- that's the- seems right. Um yeah but we are also trying to implement something like that on the- on the same side uh. So it doesn't have to be CEM but we do um- just letting the- the AS2 implementations know that there- there will be some sort of um need for automating your- your root certificate and pushing those out to your partners so that they um- so as they expire that you have um that you're able to give them the newer certificates. That's all I'm saying here. Um we can discuss this also on the list and- and get everybody's feeling on it. Uh Joe, go ahead.
Joe Mandel: So I haven't seen anything about the root certificate being reduced to a 47-day validity. I think it's on the end-entity certificate.
Debra Petta: The end-entity not the root?
Joe Mandel: Right.
Bojidar Ivanov: Yeah. 47 days for root would be impractical. I see intermediate they're recommending three years, so... the end certificates they can change every day. It's okay.
Joe Mandel: Yeah it's on the I believe it's on the the leaf end entity uh because if CAs had to run a key ceremony to update their roots every 40- 47 days it would be- it would be too much of a burden.
Debra Petta: Okay. I will make a note of that and and we can discuss it further in the um- in the E-list.
Joe Mandel: Okay.
Debra Petta: Thank you. Um all right. Let's move on to the next slide. Um Enhanced Security Considerations. So the security considerations in section 10 have been substantially expanded from the original version. In the original RFC 4130, there was just a basic security discussion. In RFC 4130bis, we've expanded to include additional security that protects against replay attacks, man-in-the-middle attacks, um denial of service attacks. It adds key management best practices, certificate storage and protection requirements, MDN forgery prevention, privacy considerations, that is- um what information is exposed in the AS2 headers and adds logging and audit trail requirements for non-repudiation and compliance. Additionally, the new subsection 10.1 um includes HTTP TLS requirements that have been added, which we've already discussed in detail in the prior slides. Um this gives implementers comprehensive security guidance instead of the minimal discussion that was provided in RFC 4130. Um next slide, please. So- there's four discussion points on security. And I know we've been talking about these as we go so maybe we don't have to- to beat on it here. But um we're saying then that HTTPS will be required, um TLS version recommendations- we- we can talk more about that, but TLS 1.2- um go ahead Marc.
Marc Blanchet: Uh didn't want to interrupt your- your sentence. I was going to- talk about the self-signed TLS certificates. Um and uh you said a SAN extension. Um we have been using self-signed TLS certificates with with no, you know, I mean it's just a public key, right? That the the other party uh decide to trust, right? So and uh you wrote uh with hostnames and IP addresses uh that creates a whole set of issues by itself, right? Because if you are behind a NAT and- and if you're using V4 or V6 and- and maybe you're using V4 one time, V6 the other time. Um so uh you know operationally speaking, I'm not sure it brings real value um because if it's not, you know, it's not a real certificate with a, you know, trust chain, then the other party has to essentially explicitly uh you know trust that- that key, right? That public key. The fact that is it's embedded into a certificate is actually, you know, not really relevant itself, including the fact that you could add a hostname or IP address in it. So- I- I don't know, it- it's about, you know, people but uh I would be uh careful in thinking that adding that extension the SAN will actually help, it will maybe actually be worse operationally. But, you know, other people can have different opinions.
Debra Petta: Okay. Um-
Bojidar Ivanov: Just- just to respond, if we previously there was a requirement not only to verify the- the chain, but also authenticate the host. Um so if it's an IP, uh you have to- you have to have that in the- in the certificate in order for the authentication to pass.
Marc Blanchet: Uh right, but I was talking about self-signed TLS certificates, not the normal certificates.
Bojidar Ivanov: But it- it- it's valid for them as well. Right, if you connect to a- a system by IP, for example, and it's using a self-signed, you need to have the- trusted root CA to verify the chain, but you also need to look up the IP from the certificate that it matches the host you're connecting to.
Marc Blanchet: Uh again, I'm fine but operationally you'll- you'll find- you'll find issues about that.
Bojidar Ivanov: Yeah, okay.
Debra Petta: Okay. All right. Does anybody have any other comments from the section that we just completed? Um I know that we've been discussing per slide so some of this stuff may be overkill. Hi Erik, um what's your comments?
Erik Wramner: Hi. Uh first I wondered did I get the time wrong because it seems you have been going for quite some time?
Debra Petta: Yeah, we started an hour ago.
Erik Wramner: Okay. So then I got the summertime change wrong. Sorry. Uh anyways, um what I was going to say was uh I don't think we are using CEM much for changing TLS certificates, it's- it's very widely used or rather it's getting traction at least for AS2 certificates. But- but in this context here you're talking about using it for actually changing the TLS certificates and- and in my view that is not really needed because 47-day or not, the root certificates they stay as they are basically or are updated on the operating system level and the um uh well the- the server's own certificate- um is trusted because the root certs are trusted. So I- I really think we should support CEM, but I think it should stand on its own merit, which is uh that it can help with the AS2 certificates. That's all.
Bojidar Ivanov: I- I made the same comment, I agree with you.
Erik Wramner: Okay.
Debra Petta: All righty. Okay. Does anybody have any other comments from this section? Okay. Let's move on um to the next slide. We'll start talking about backward compatibility. Um so- we're going to move on to backward compatibility and a migration strategy. Great. Um next slide and that's the Ensuring Smooth Transitions. Sessa - rfc4130bis So our guiding principle for our backward compatibility strategy is be conservative in what you send and liberal in what you accept. Um this is the robustness principle and it's also known as Postel's law. Um the suggested- suggested implementation approach, modern implementations must support new algorithms, modern implementations must send using new algorithms when both partners are capable, modern implementations may accept legacy algorithms when the other partner still supports just legacy algorithms. The backward compatibility discussion um that- in the- in the spec that was previously in Appendix B has been moved to section 1.2 closer to the beginning of the document. Um this was requested after- um our- our first section- our first meeting. Um so this is a non-normative section, it's guidance, it doesn't- it's not requirements. It provides detailed guidance on handling RFC 4130 partners. It includes algorithm negotiation strategies, graceful degra- a graceful degradation approach when a partner doesn't support modern algorithms and potential migration timeline recommendations. I want to stress that there can be no breaking changes, this is critical. A conformant RFC 4130 implementation remains conformant to RFC 4130bis. Um new implementers get full guidance in RFC 4130bis. They don't need RFC 4130 as a reference. Um next slide. Um this- this slide um shows two specific interoperability scenarios for S/MIME versions. Um on the left, when a partner uses S/MIME 3.2. Um so you- the scenario, your legacy partner only supports enveloped data not auth enveloped data, your implementation uses enveloped data with AES-CBC encryption. Um this would add a digital signature separately for- excuse me- for integrity protection, it's a two-step process, sign then encrypt. Um this is acceptable and a completely valid AS2 transaction under RFC 4130bis. You're not breaking any rules. On the right, when both implementations support S/MIME 4.0. In this scenario both you and your partner support S/MIME 4.0 capabilities. Your implementation uses auth enveloped data and that's an AES-GCM or AES-CCM um for authenticated encryption. It's a single operation that provides both encryption and integrity. This is recommended and would be the preferred approach for new partnerships. The key is your implementation needs to support both approaches. You would do this by detecting your partner's capabilities either through the AS2 version header or through capabil- capability negotiation and adapt accordingly. Next slide, please. All right. Um more discussion for backward compatibility. Is the backward compatibility and legacy interoperability section sufficient for migration guidance? Should we provide more specific timelines or sunset dates for legacy algorithm support? Or should we leave that to the individual organizations based on their partner ecosystems? I know it was previously stated that we can't control what implementations do, so my guess is that we would have to leave it to the individual organizations. Um the overall approach for document structures, some contributors had suggested splitting this work into two documents. Um RFC 4130bis, um the minimal update was- with just errata and critical security fixes, um and then having an AS2 version 2 with clean modern baseline without legacy algorithm baggage. Or- or should we keep it as a single comprehensive update? Um there's arguments for both ways and we can discuss on the list if- um if we don't want to talk about it here.
Asger Smidt: I think that discussion is probably too big and will take too long for it to make sense to discuss it here.
Debra Petta: Okay. Well- we- what we can do is open that as a- a conversation on the list and- and talk about it there. Marc or Bojidar?
Marc Blanchet: Um well- um I agree and disagree at the same time with the previous comment, which is um and kind of in my chair hat on experience in the IETF is uh the virtual meetings or the actual physical meetings are, you know, quite- you know, are there for um high bandwidth discussion and reaching consensus. So sometimes it takes time to reach consensus, but uh often it's way better to do this especially if the participants are there than having a thread of a zillion emails that you can't find the right, you know, what's consensus. So there's pros and cons. On the IETF way, a process way is everything that is reached consensus during a meeting need to be verified on the mailing list so that people who are not present during the meeting are not disadvantaged in the sense that they should- they have the appropriate uh- um way to- to say what they think. Um so- I agree that we're- we're spending a lot of time but actually it's a big spec. So- um it's fine that we take a few interim meetings to discuss and go there. I see right now that we're making a lot of progress and consensus and discussion. So to me all this even if it takes, you know, two- well three hours total right now, it's actually very useful. So um I- I have to discuss with Joe, uh but my think is maybe we should have like a monthly meeting interim virtual meeting and we'll continue there until we get the whole spec done. Uh and having at the same time parallel discussions on the mailing list. Just my take.
Asger Smidt: Uh to be clear I perfectly agree with you. All I'm saying is we don't have enough time left in this meeting to have this discussion.
Marc Blanchet: Yeah. Agreed.
Bojidar Ivanov: Yeah. Uh I was going to say it's too big for a mailing list. We're more efficient in person. So if we need another meeting I would prefer we discuss it in another meeting.
Debra Petta: Okay. So maybe- why don't we get through the rest of the slides and then we can come up with a- an agenda for- for the next meeting, for- perhaps next month, Marc, if that's what you think.
Marc Blanchet: Yeah, yeah. Makes sense.
Debra Petta: Okay. All right. So then let's move on and then um when we're- when we're done with this one we'll- we'll figure out the agenda and- and see what we can talk about next month. Um so- and this has already been brought up, but the IANA considerations section has um- we'll be making updates there and there- I think there were some. But let's move on. Um next slide, please. So section 11 covers the IANA registry updates. Um this is pretty straightforward. Um RFC 4130 will update the existing registries, we're not creating new ones though. Um the media MIME media type registrations update from RFC 3335, that was AS1. RFC 4130 is AS2. We're not making any new media types, um we're not adding any new ones. Um we will then be adding MDN disposition modifiers aligning with um 8098, clarifying usage of the existing modifiers. We will need to register the new disposition modifier extensions that we discussed in the previous sections. Um AS2 header field registrations, um document the AS2-from, AS2-to, AS2-version that are already- already in use, now formally registered. Uh we can add an AS2-product header um if that's agreed that we will be using that and anything else we decide to add. Um the important thing is that we're not adding new registries, um this is about updating and clarifying existing registries only. Next slide. Okay, so this is the final discussion and next steps. Um so let's wrap up with next steps and how to provide feedback. Um next slide, please. So here's how to engage with this work going forward. Uh we have an official IETF data tracker. Sessa - rfc4130bis Um I'm sure that you've all seen this and used it. And then there's a GitHub repository with the- the actual specification. Uh you- you can provide it there or provide your comments in the list and we can make the changes and then update those into the data tracker. Tracker. Um how to provide feedback, uh either through the email list, um that's the primary channel. Uh you can also contact me directly if you choose. Marc, go ahead.
Marc Blanchet: Uh yeah, chair at on. Um so the use of GitHub with especially the issue trackers of GitHub is- has pros and cons in the IETF process because the IETF process has been for 50 years or so using mailing list to discussions. And for some working groups they've been using GitHub issues and then having that discussion there in the issue tracker. Um so right now we don't have to my knowledge a- formal policy for that, but I- I just want to make sure that people understand that still the mailing list is kind of the normative way of doing discussions. So you could issue uh write issues or PRs or stuff but make sure that the actual discussion happened on the mailing list, not in the issue tracker or the, you know, in the PRs.
Debra Petta: Okay. We haven't really had any PRs as of yet. I have been doing all of the modifications to the spec, putting them in GitHub and then pushing it out to the data tracker. Um we can in the future use it if- if that's agreed upon, but we can stay with the mailing list if that's acceptable. Amir, did you have a- a comment?
Aamir Shaikh: Yeah, the slides uh can you send that out also if possible?
Marc Blanchet: They're on the data tracker. So um you know if you look at the data tracker, the meeting, uh the group um EDIINT and then you see meeting and then you go into that the virtual meeting you'll get all the materials there. Chair Slides
Aamir Shaikh: Okay. All right. Thank you.
Debra Petta: If- if Amir, if you still have um still can't get to it though, if anybody still has issues and would like copies of- of that- those slides, you can email me directly. Um my email address is on the next slide if you'd like to move to the next slide and you'll see that there, um deborap@drummondgroup.com. If you- if you contact me I can send you those slides as well if you'd like them. Um but thank you all for your time and engagement over this and the past session. Um this has been pretty detailed. I appreciate everybody's participation. Um so we can decide going forward how we want to structure our meetings. Uh Joe, did you want to make a comment?
Joe Mandel: Uh yes. Thank you for the presentation. Uh I was going to run a couple polls uh before we- for the day. Uh so the first- let me get it ready. One second, I need to modify it. First time doing a poll so bear with me.
Marc Blanchet: So while Joe does that we are going to do a few polls. So this is not, you know, in the IETF process uh decisions, this for the chairs to get a feel of the working group uh opinions. And- so you're very, very encouraged to actually respond to the poll. It's all anonymous. We can't see who uh voted or, you know, say yes or no in- in polls. But uh it's very useful for the chairs to see where we're going. Are you okay Joe or...
Joe Mandel: Okay. That's coming. Okay cool. One second I need to modify it. First time doing a poll so... All right. Now it's ready.
Marc Blanchet: So um so people please uh say yes or no or no opinion on the first poll which says should the EDIINT working group adopt draft-petta-rfc4130bis as a working group document for the milestone. What that means is if we adopt it then it becomes a working group document, that doesn't mean that you agree with everything in the document, it just says should we use this as the base document for- for the milestone. And the other thing is as soon as it becomes a working group document it is- it is a working group document so the working group has actually the power to change things in the document. The author or the editors become just editors of the consensus. So that's what we're asking. It's not the final publication request, which will come a working group last call later. All right. Looks like most people responded so I'm going to close this one uh will follow up on the mailing list. So to summarize for the notes is that we have 13 yes, zero no and zero no opinion. So it's- uh at least for the people present on the- on the meeting it's- uh it's not only consensus but a full agreement. Um but as I said before because the IETF process we will send an email to the mailing list with the same question or referring to this and confirm reconfirm if there's consensus in the working group for this discussion for this uh poll.
Joe Mandel: All right. I'm starting the next one. Uh this is about do you plan to attend the next IETF meeting in Vienna um from July 20th to the 21st. Uh and whether or not you'll be in person. We're trying to get a sense of uh how many people plan to be there to uh request a a timeslot and room. All right. I'm seeing only two people are going to be attending um in person and right at time. Uh so thank you everyone for being here.
Marc Blanchet: Joe so um I- I think one of the yeses is me so uh, you know, I'm the chair so- co-chair so- I'm not sure I'm counting but I wanted to make sure that, you know, I'm also working group member. Um so it looks like from what we've seen here uh that we may want to run the meeting um- you know mostly virtual with kind of monthly uh, you know, frequency or something like that. Is that something that people think it's the right thing to do or given that not everybody actually almost nobody goes to the IETF on-site uh meetings? Does that make sense for people to have a roughly monthly uh meetings virtual meetings? Any comment?
Asger Smidt: Sounds good to me.
Debra Petta: Sounds good to me.
Bojidar Ivanov: Same.
Tian WAN: Same for me.
Marc Blanchet: Okay Joe so I guess we should probably plan for that.
Joe Mandel: Okay. Mark did you have anything else?
Marc Blanchet: No. I think we are ready for closing the meeting.
Joe Mandel: All right. Thanks everybody.
Debra Petta: Thank you. Have a great day.
Joe Mandel: Okay thank you. Take care.
Debra Petta: Thank you. Bye bye.