Roger, thanks for putting the notes together. Later during the day yesterday, i came up with a very simple requirement that i think would cover my concerns regarding mixing in launch phases in the fee document:
- The Fee Extension MUST provide full functionality with registries implementations which are unaware of the Launch Phase extension. I think that pretty much covers it. Everything else would be dangerous mixup. My personal preference is still to investigate why exactly the "class" functionality does not cover Thomas' use cases anymore, because i'd like to see the launch phases be completely disconnected from the Fees document. best, Alex Von: regext [mailto:regext-boun...@ietf.org] Im Auftrag von Roger D Carney Gesendet: Dienstag, 11. Juli 2017 20:55 An: regext@ietf.org Betreff: [regext] REGEXT Interim Meeting [x_phishing] Good Afternoon, We held an interim meeting this morning and discussed the current Fee draft document (draft-ietf-regext-epp-fees-05). In attendance was Thomas Corte, Jody Kolker, Antoin Verschuren, Alex Mayrhofer, James Galvin, Scott Hollenbeck, Joe Snitker, and Roger Carney. We started by confirming that the current revision of the document (v5) addressed all currently known issues (except the <fee:command> "minOccurs" issue that Thomas raised on the list two weeks ago, which will be addressed in next revision). We moved on to discussing any new issues/concerns, three items were raised: 1. First of which relates to section 3.8 and specifically what happens when a client does not provide a phase/subphase. We spent the majority of the meeting, roughly 45 minutes, discussing this item. Initial comments were that this functionality seemed to be an over reach for this document. Originally Alex thought that a compromise might be that we change the "should"s in paragraph 2 and 4 to "MAY"s. The group talked this through and said that was possible but generally it was still thought to be over reaching. The group concluded that the best approach maybe to: * move this phase/subphase listing functionality out of this document and into the draft-ietf-eppext-launchphase document; * remove paragraph 2 and 4 of section 3.8; * add text to section 3.8 to handle clients not passing in phase/subphase: i. where there is only one active phase/subphase server MUST return phase/subphase and appropriate fees, ii. where there is no active phase/subphase server MUST return a reason that there is no active phase at this time, iii. where there is more than one active phase/subphase server MUST return a 2003 "Required parameter missing" error 1. Scott mentioned that we need to add a normative reference to the draft-ietf-eppext-launchphase document as we refer to it in 3.8. This is planned for the next revision. 2. Lastly we touched on the subject of the <fee:cd> "avail" attribute. James poised the question of value versus complexity. Do members of the WG understand the purpose of the <cd:fee> "avail" attribute? Do we need more text in the document to help explain intent? Do we gain enough value by introducing another level of availability? Additionally, we talked about including support in draft-ietf-eppext-launchphase to get a list of phases for a TLD and a list of current active phases. Scott was going to bring this up to James Gould as well (Gould was one of the authors of the launch phase document). We would like to get WG thoughts and comments on any and all of these items so that we can gain a rough consensus and get closure of these items. Next week in Prague, at the REGEXT meeting Tuesday at 13:30 local time, I will provide an update on how the interim meeting went and on the draft. The plan is to get rough consensus on the changes needed for the next revision of the Fee document, and shortly after IETF-99 produce revision 6 and look to go to WG last call. If anyone has any additional thoughts on these topics or new topics for the Fee document please let us know. Thanks to all of you that participated this morning, it was a very productive meeting. I look forward to seeing most of you next week. Thanks Roger
_______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
