Current Meeting Report
Slides
Jabber Logs


2.1.12 Provisioning Registry Protocol (provreg)

NOTE: This charter is a snapshot of the 55th IETF Meeting in Altanta, Georgia USA. It may now be out-of-date.

Last Modifield: 07/08/2002

Chair(s):
Jaap Akkerhuis <jaap@sidn.nl>
Ed Lewis <edlewis@arin.net>
Applications Area Director(s):
Ned Freed <ned.freed@mrochek.com>
Patrik Faltstrom <paf@cisco.com>
Applications Area Advisor:
Patrik Faltstrom <paf@cisco.com>
Mailing Lists:
General Discussion: ietf-provreg@cafax.se
To Subscribe: ietf-provreg-request@cafax.se
In Body: subscribe ietf-provreg
Archive: http://www.cafax.se/ietf-provreg/maillist/
Description of Working Group:
Administration of Domain Name Service (DNS) registration increasingly distinguishes between the operation of a "back-end" registry data base service for registrations, versus "front-end" support services by registrars who interact with registrants and with the registry. Especially for various Top-Level Domains, the desire is to permit multiple registrars to share access to the database. Conversely, there is a desire to allow a registrar to access multiple registries via the same protocol, even if the registries differ in operational models.

This working group will develop a specification of the requirements and limitations for a protocol that enables a registrar to access multiple registries and will develop a protocol that satisfies those requirements. The protocol will permit interaction between a registrar's own application and registry applications.

The initial specification will allow multiple registrars to register and maintain domain names within multiple Top Level Domains (TLDs). The specification should be flexible enough to support the different operational models of registries. The specification should allow extension to support other registration data, such as address allocation and contact information. The working group will use as input the "Generic Registry-Registrar Protocol Requirements" (draft-hollenbeck-grrp-reqs-nn) and the Extensible Provisioning Protocol presentation, documented in (draft-hollenbeck-epp-nn).

The group will consider support for multiple operational choices, such as for transport and security; it will create no new transport or security protocols. The group may consider use of the new protocol for diverse registration and update scenarios, in order to understand limitations and possible extensions that are appropriate. Specification for user interface access, such as by a web front end, is beyond the scope of this working group.

Documentation from the working group will:

* Specify the objects exchanged between the registry repository and registrars, the relationships among the objects, and the protocol for exchanging objects between a registrar and the registry; at a minimum the objects will include: domain name, IP address, and contact details for registrants

* Describe appropriate mechanisms for security during registrar access

* List useful examples of registrar access transactions

Goals and Milestones:
Done  Working group agreement on functional requirements for protocol
Done  Initial specification of provreg protocol
Done  Second draft specification
Done  Decision on whether to drop containers
Done  Second draft of EPP over BEEP
Done  Second draft of Containers
JUL 02  First draft of EPP over SMTP
JUL 02  Decision on need for a EPP Guidelines draft
NOV 02  Schedule interoperabilty test
Internet-Drafts:
  • - draft-ietf-provreg-grrp-reqs-06.txt
  • - draft-ietf-provreg-epp-06.txt
  • - draft-ietf-provreg-epp-contact-04.txt
  • - draft-ietf-provreg-epp-domain-04.txt
  • - draft-ietf-provreg-epp-tcp-04.txt
  • - draft-ietf-provreg-epp-host-04.txt
  • - draft-ietf-provreg-epp-beep-02.txt
  • No Request For Comments

    Current Meeting Report

    Action Items:
    1. Respond to the IESG comments.
    
    Most of the comments are easily addressed.  A few need further 
    discussion (and are listed as separate action items).
    
    2. Come to a final understanding of UDP and EPP.
    
    There have been some words posted to the "outlawing" of UDP, one 
    response was to require stream based protocols.
    
    3. Clarify the adoption of P3P concepts.
    
    P3P was written for website environments, not a business to business 
    situation.  This is reflected in some of our examples and needs to be 
    cleaned up.
    
    Rick Wesson volunteered to summarize a discussion on privacy issues. It 
    might be up to us to forge new ground here as we are one of the few 
    protocols that gathers personal information (for registration 
    information).
    
    4. Whether or not we adopt a work item for the SOAP 'as transport' draft.
    
    A thread has been started on the list, but the results are luke warm for 
    now.
    
    5. An SMTP mapping is all but dead in the water.
    
    Unless someone objects on the mail list, we're dropping all 
    milestones relating to SMTP.
    
    6. Continue to progress on Guidelines.
    
    No sense of urgency, at least not until we get #1 above done.
    
    Two other action items...
    
    7. Clean up the milestones.
    
    After the meeting we talked and decided that the milestones on the web page 
    aren't sufficiently descriptive.  Before fixing them, #4 and #5 need 
    answers.
    
    8. Discuss 'lastVerified' - mandatory, extension or optional
    
    9. Discuss handling of external hosts
    
    Details on meeting discussion:
    IETF provreg Working Group
    ==========================
    9.00-11.30 Slot, IETF 55, 19 November 2002
    
    Chairs: Ed Lewis and Jaap Akkerhuis
    Author: Kim Davies
    
    
    IESG Comments on EPP Drafts
    ---------------------------
    
    Comments by Ed Lewis (EL)/Scott Hollenbeck (SH):
    
    1. Do we place mailing list names and URLs in RFCs?
    A: Removing that section.
    
    2. Would like a stronger Security Considerations section, Wants it to say 
    that that EPP "MUST NOT be used over a transport mechanism that does not 
    provide confidentiality", or "All transport mappings for EPP..."
    A: Incorporated. Clear text passwords are used, so privacy is 
    required.
    
    3. What is "authorization token"?
    A: Changed to "authorization information" to be consistent with rest of 
    document.
    
    4. Does EPP need the login/pass command if it is using TLS 
    authentication?
    A: Yes, TLS is using machine to machine authentication. user-level 
    authentication gives greater granularity. Some greater explanation is 
    needed.
    
    Scott Bradner:
    1. More strict about congestion control protocols require an IETF 
    standards track congestion control such as TCP or SCTP.
    A: Will address this later in response to another comment.
    
    Bert:
    1. example.tld is not an approved example.
    A: Was not aware of the convention for example TLDs. They will be 
    changed appropriately.  What should be used for IPv6 examples?
    Patrick Faltstrom: Will ask the IESG for guidance.
    
    Randy:
    1. Why is there no granular privacy options for domain/contact 
    mappings.
    A: Raised some discussion. Extensions allow policy to be codified on a 
    case-by-case basis. Needs to be discussed by the WG.
    
    Allison:
    1. <replacement text for managing congestion>
    A: <will discuss later>
    
    2. Define "marketing" add a more neutral definition.  More 
    explanatory material will be added (from P3P website or similar)
    
    3. How does IESG and the community check XML (as opposed to ABNF or MIB 
    checking)
    A: Available checkers from W3C etc.
    PF: IESG may more thoroughly define this in the future, only just 
    implemented requirements on ABNF grammars.
    
    4. Suggest that limiting the number of TCP connections is not a good thing 
    for net services. change MAY establish to SHOULD NOT. A server MAY limit 
    becomes SHOULD limit.
    
    5. Missing TCP reference needs to be added
    
    Discussion
    ----------
    SH: Any problems with the suggested replacement text (from Allison Q4) that 
    clients should not establish multiple tcp connections, and the server 
    should limit connections.
    
    Rick Wesson (RW): Ignores practices in common place
    
    Jon Peterson (JP): ...
    
    EL: This is used to address server load, not network load. This also has 
    considerations for both.
    
    JP: We might want to recast the sentence to consider that.
    
    RW: It would be nice to have the actual language rather than the 
    substitutions.
    
    The wording as suggested on screen:
    An EPP client streams EPP commands to an EPP server on an 
    established TCP connection.  A client MAY but SHOULD NOT establish 
    multiple TCP connections to create multiple command exchange channels.  A 
    server SHOULD limit a client to a maximum number of TCP connections based on 
    server capabilities and operational load.
    
    RW: Seems we are touching up language that ignores that 
    operationally this happens (multiple connections) normally.
    
    EL: SHOULD NOT helps convey that it is discouraged, and that 
    implementations shouldn't make this default behaviour.
    
    Patrik Falstrom (PF): The definition for SHOULD NOT does not forbid it if 
    there is a justification.
    
    RW: It is good to encourage clients not to do it.
    
    JP: It contains a provision for clients and servers. If the server limits 
    the number of concurrent connections it will persuade the clients not to.
    
    PF: The client should not just open multiple connections without 
    justification. The server can still reject the connections. The 
    important reason for including the wording is that those claiming to the 
    conformant to this RFC will only implement software with concurrent 
    connections only when it is really needed. I.e., Clients should reuse open 
    TCP connections rather than open new connections wherever possible.
    
    <no more comments>
    
    Transport Comments (congestion and reliability, Allison-1)
    
    --------------------------------------------------
    EL: This is the suggested wording from Allison. "The transport mapping MUST 
    be onto a transport such as [..] and so forth".  The last part is a 
    concern that SMTP runs over TCP, that the SMTP 
    store-and-forward may drop transactions. The first part is that the Layer 4 
    connections don't impact the network.
    
    PF: Also note, the second part, talks about SMTP/BEEP doesn't include any 
    MUST or SHOULDs. This is a reminder for transport mapping authors, that 
    they need to think about these issues and contain some wording on these 
    matters.
    
    EL: Any comments on the proposed text?
    
    SH: Not advocating this position, but Eric B-W's comment was that his work on 
    UDP transport would be affected by this.
    
    PF: I suggest that because Eric brings up this issue, that the WG 
    summarizes the issue that Eric has and pass it back to Allison. You could 
    get Eric to do this. I don't think that the WG should declare rough 
    consensus and ignore Eric's comments without consulting with Allison.
    
    RW: When did Eric make this comment?
    
    EL: In recent weeks, and I think it was alluded to in the SMTP draft.
    
    SH: I think it was right after the IESG comments were sent to the list.
    
    Simon ??: Many UDP protocols handle this like RPC 
    implementations that do retries, back-offs etc. It should be in the 
    transport mapping. We shouldn't expect anything more from the 
    transport ADs.
    
    JP: I'm surprised by this. Is there some reason for using UDP?  Seems to be 
    this is a real long-shot, and needn't go to Allison unless people think it is 
    credible.
    
    PF: My feeling in IESG discussions, is that the experience from the 
    Transport ADs, that messages with one round trip (from SIP etc.) but as the 
    protocol grows you implement retransmissions and back-off 
    algorithms, so over and over again people who use UDP fails.
    
    RW: I don't feel it is appropriate to do this over UDP. I think that 
    without a draft on this we should just move on.
    
    anon: Don't make it completely illegal though, some of the stuff I am 
    doing is very lightweight, where if a connection fails it can just be 
    retried. Other people are doing things with UDP that are illegal.
    
    RW: More specific?
    
    anon: says discussion is not on-topic for WG
    
    EL: BEEP mapping failed because no-one wants to work on it as a group. We 
    have new mappings coming in - do we want to work on those in this group?   
    Does the doc go out prohibiting UDP or just not mentioning UDP? We could 
    just ignore datagram protocols, say something. I don't want to specify how to 
    do this over a datagram.
    
    I'm not sure how to approach this - leave it unmentioned? I'll talk with 
    Patrick about that.
    
    PF: Summarize the issue. See if people don't want it prohibited to do this 
    kind of mapping, and then start a dialogue with Allison. I don't hear a 
    clear consensus that doing UDP is completely stupid.
    
    EL: I think we're done with this item.
    
    SH: Are you going to take the action to coordinate this with Allison.
    
    EL: Yes, it will go on in the minutes.
    
    PF: Try to talk with her here.
    
    (see the very end of the minutes for a comment from Allison as relayed by 
    Patrick.)
    
    Privacy comments
    ----------------
    EL: The last of the major talking points in the IESG comments involves 
    privacy. Allison had this specific comment regarding marketing 
    purposes.  And then Randy's comments on privacy meta-data on a more 
    granular level, down to objects and aspects and so on, rather than the 
    whole session. Where do we want to go with this?
    
    SH: Lets begin with a little explanation on how we got here. Since the 
    beginning, the topic of privacy came up 1-2 years ago, and a few folks 
    proposed a strawman proposal on granular privacy tagging - but it never 
    came forward, so we went around in circles.
    
    Instead, we punted to the extension mechanism in the protocol now - so 
    specific privacy policies can be implemented with the extension 
    mechanism.  So if email addresses are private, an extension could tag the 
    element for this purpose.  There isn't a lot of text describing privacy and 
    using extensions to implement this, and we could do this if necessary - but 
    the IESG did not ask for this, it asked for more specific privacy.
    
    JP: In a P3P sense, it is clear cut how it is used. But in this B2B 
    context, what does this mean for contacting for marketing purposes? What 
    does it mean?
    
    RW: In the context for the P3P sense, it only appears to be 
    applicable for web pages. There doesn't seem to be any way to do this, it is 
    an immature way to address the privacy issue. I don't know if what we have is 
    extensible. I like that approach.  Different registries can develop 
    policies. But putting a tag on each and every element seems like a simple 
    way to solve a problem - but as we don't have any operational or policy 
    sense on this, we have no way of knowing if it will work.
    
    Rich Shockey (RS): I want to concur with Rick on this. The idea that 
    privacy is associated with objects is a good idea. We dont have a 
    standard to apply to the EPP objects at this stage. Last week in Dulles, VA, 
    the W3C had a workshop on P3P on its applicability outside web pages. They do 
    not have a work plan, or anything associated to present.  We could go down 
    this road, but int he absence of any other technology (and I would assume 
    the W3C will take years), as much as I'd like to see something 
    implemented, I don't see how we could practically do it.
    
    RW: Privacy is good. Some way of enhancing a registrants, or 
    expressing that privacy, is good. I just want a mechanism that is more 
    flexible and tested.
    
    RS: I am in total agreement. This could delay the work by orders of 
    magnitude.
    
    EL: There are two types of granularity... Per-item and per-purpose.
    
    SH: I was asked if I had any opinions. Personally, I think the protocol 
    addresses this requirement. It allows us to move forward without putting 
    restrictions on how it is defined in the future. The protocol still 
    depends on the extension mechanism to define what private means. The 
    document implies that you must  use the extension mechanism.
    
    EL: One suggestion was that, and if you see Randy's comment, that the 
    contact details are the ones needed privacy and maybe we only define it for 
    those objects.
    
    RW: If we have something that worked for all situations, we would 
    appreciate it if we could just take something and use someone else's work. We 
    may not be qualified to do this kind of work.
    
    JP: This is a common refrain, we had the same thoughts in geopriv. We have 
    nothing there, and we don't have anywhere to go.
    
    RS: That's funny, because we are looking to geopriv.
    
    RW: It doesn't exist - are we the right people to develop it?  Should it be 
    in the context of another group?
    
    EL: Maybe we are the right place because we are one of the only places 
    dealing with these matters.
    
    RS: My personal suggestion would be the WG chairs ask the IESG for 
    clarifications, with the comments we have no technical basis or 
    competency to tackle the issue.
    
    EL: I want in the minutes that the P3P, where the documents come from, is a 
    good document, but we're not sure is applicable.
    
    RS: I am happy to post the results from the Dulles, Virginia, 
    workshop, they are  working on this and cognizant of the limitations it 
    has. There are companies that  are looking to do clever things with this. 
    But is there a body of work to apply to provreg and EPP? No. When could we 
    see one? God knows.
    
    JP: IESG's comments suggestion seems to only be some tweaks - and that we 
    are on the right track. Maybe we are doing a good job, and we 
    shouldn't decide to change focus and do something else entirely.
    
    EL: ...
    
    RW: We have not just the registrar-registry model, but we have reseller 
    chains that must express this information and how it applies. It might be 
    somewhat clear in the simple R-R model. I believe there is a whole lot of 
    work to be looked at here.
    
    RS: This is a question on how the policy can be passed to 3rd and 4th 
    parties in a chain of trust. To make it perfectly clear, if there was a way 
    to do this in a reasonable or rational way - we need a few proposals on how 
    this could be done without complicating the process too much. I think the 
    extensions proposals are the most reasonable way to do this.
    
    EL: I do want to .. I'm not sure if we have to worry about. Right now we are 
    looking at the EPP protocol for R-R. Do we need to look at the EPP 
    protocol from registrar to registrant? Does it need to be addressed now?
    
    RW: If you are not talking about privacy, I agree we don't need to 
    address it.
    
    EL: Why is it special for privacy?
    
    RW: It is the entity that is making the registration, so if you have 
    reseller chains, in a privacy context, there is a lot of liability - 
    countries, laws etc. and it is not at all clear to me how it will work.
    
    EL: I think we are done with the IESG comments. We have to discuss UDP, 
    Privacy, etc. so we can't just rubber stamp it. But we have addressed most 
    comments apart from these few things.
    
    SH: A request for clarification. Is there going to be a WG response to take 
    back to the IESG? If we ask the IESG for clarification, then we have to 
    rediscuss it here.
    
    EL: I think we can have a mailing list discussion over the next 2-4 
    weeks.
    
    SH: I would like to see some kind of position.
    
    EL: Some new issues have come up. Passing information up and down. We 
    could sit down and consider types of privacy.
    
    RW: I would suggest we enumerate the kinds of things we have looked at. We 
    shouldn't go down the road of defining privacy as it is too much work.
    
    EL: Another comments is this doesn't apply as this is B2B.
    
    SH: I think the P3P discussion, and privacy, are somewhat separate.
    
    EL: I think based on the fact we have these small comments that we only 
    need to make small changes.
    
    SH: There is no indication we have got this completely wrong.  Who is 
    going to make that happen? Our chairs?
    
    EL: Our chairs.
    
    RW: I volunteer..
    
    EL: We have two things to think about - UDP and privacy.
    
    2.5 other issues with the base 10m
    
         Last-Verified and External Hosts
         (Presentation attached.)
    
    RW: Several weeks ago, a number of groups have an issue with WHOIS. 
    -quality assurance In the context of registrant data.. one being the 
    postal element, on how it can change - not in the db, but in the real 
    world. Such as change of a zip code or reassignment of a street 
    address. PSTN elements change over time too - phone numbers get 
    remapped. It is happening in India at the moment, where the length of 
    numbers are getting changed. In the US, Area codes changes. If we had a 
    registration 10yrs ago in the LA area, and the area code would be 
    remapped and would change. Then the data in our systems isn't being 
    remapped or changed.  I advocate a position where we identify the time 
    since a contact acknowledged that they have accurate and correct 
    information.
    
    The proposal is for a last-verified-date, since the registrant ack'd the 
    data is accurate. It would be optional in EPP for the contact.
    
    Comments?
    
    <none>
    
    EL: OK. On the mailing list, the last message on this talked about this 
    being optional. Not everyone agreed that all registries. So this is the 
    question i am most interested in. Should it be optional?
    
    RW: From the comments i have received it makes the most sense.
    
    JP: It doesn't seem to make any sense to make it mandatory. There are all 
    kinds of bad things about it.
    
    SH: I agree, it seems appropriate. The last comment was more strong that it 
    should not be in the base, but i agree with RW on this.
    
    RS: Ditto.
    
    EL: We have documents in from of the IESG and I am not sure if we want to 
    make a change at this stage.
    
    RW: The IESG knows about this.
    
         External Hosts
    
    EL: The other item is the external host, external objects.
    
    SH: OK, here is another can of worms that was discussed in great details 1-2 
    years ago. TO set the stage. We have an issue with repositories being 
    authoritative for objects in other repositories. i.e. Hosts being used as 
    nameservers, being renumbered etc. This causes management issues if the 
    entity that owns the host doesn't sponsor the object in the registry. An 
    alternative proposal was that each client sponsored its own copy of these 
    objects, allowing each client to manage their own. Hopefully there was no 
    restrictions on this, prevents hi-jacking. It allows for bulk updates, you 
    change one objects and it percolates through all objects that are 
    associated. This is something we need to resolve before we move 
    forward.
    
    JP: I am not sure about this issue. I can't speak for Hong.
    
    SH: Hong's objections were this per-client copy, but instead these sorts of 
    objects are managed by the server. I don't like the owner word, I forget 
    what the arguments against what that were - it seems rational. If we 
    assume no objects belong in the registry if they are not 
    authoritative, we can throw out these objects and make nameservers 
    attributes of the domain objects. This has problems with bulk updates.
    
    EL: The fear is that using the same nameserver for a lot of zones, that 
    would mean a lot of changes if I change nameservers.
    
    RW: We have to do it one way or the other, and each has 
    consequences. I think we have made a decision and it is a good choice.  We 
    have a significant amount of operational experience about this choice. I 
    have not heard significant comment about this apart from Hong.
    
    EL: Any other comments on the base specification, outside the IESG and our 
    current discussions?
    
    EL: Next on our agenda is a transport mapping on SOAP. Hong is not here so 
    Jon Peterson will present on that.
    
    EPP/SOAP
    --------
    
    (presentation attached)
    
    JP: My slide is what i believe are the issues with the draft. Why would you 
    want to implement this? SOAP is more widely deployed, so it may be easier to 
    use a SOAP envelope to talk EPP. You need to define a small amount of 
    persistent session data inside the SOAP header. It is relatively 
    straight forward. There are some issues that were discussed on the list 
    that are unyet resolved. These are error codes, do we want to 
    construct actual transport protocols used by soap, and how does this draft 
    fit with existing deliverables of the provreg charter. Is this charter 
    work? Does the initial charter of provreg consider this 
    appropriate. Is SOAP perceived to be valuable?
    
    RW: Is soap an actual transport? It is a layer of indirection. There are a 
    number of bindings defined to another protocols but it is not an L4 
    transport.
    
    Andrew Newton (AN): One of the motivations of using SOAP is that 
    abstracts you from the transport, and you can use any number - but are 
    there any non-TCP transports?
    
    JP: I'd be surprised if there isn't.
    
    AN: No there isn't one.
    
    RW: What is the status of the draft?  Informational or Standards Track? If 
    Info.  I think this is great. I am a SOAP implementor and I think it 
    sucks. But that is just the state of affairs today.
    
    EL: Hong has written this and he would like it as a WG item.  That would 
    mean the WG takes over. If we think this is just a cool idea for Hong to 
    work on, that is fine.  The charter does say we should look at 
    transport mappings.  It is perfectly OK for the group to say yes we love 
    this idea - we could do that - and it could be standards track. I'm not 
    saying that we have 4 people who would love to do this.
    
    AN: SOAP is not a transport. Some people see this as a magic answer that 
    would solve all their problems. This has happened with other RPC 
    protocols.
    
    Leslie Daigle: If you want to discuss using SOAP, you should come up with 
    architectural reasons for going there.
    
    EL: Yes that is an important question.. "Why?" Why are we doing this?
    
    JP: Given how minimal the mechanism is, this is something I am here to ask 
    what the WG thinks.
    
    EL: We have already thrown out BEEP mapping because no-one else wanted to 
    work on it.  There was nothing wrong with the proposal - it was not 
    mature - but its proponents didn't pursue it any further. The problem is we 
    had not consensus there.
    
    RW: To answer some of Leslie's question. This is exactly why BEEP didn't 
    work. We didn't have the tools or constituency. Right now, the fastest way to 
    deploy the service (as long as you don't want too many people to use it) is 
    to use SOAP.
    
    EL: If we are talking about EPP, we are going to layer requirements on the 
    transport.  With SOAP being this general, how can the document address all 
    the transport layers.
    
    RW: We should have a set of requirements that the SOAP transport must use. 
    Just like the TLS over TCP.
    
    JP: I think Rick is correct with the SOAP approach. We would rely on 
    profiling on constraining you to particular transports.
    
    EL: Does this have promise? Might this be an interesting thing? Do we want 
    this in the charter?
    
    (yes)
    
    EL: Who would implement this?
    
    PF: Including specific requirements all the way down the stack to IP - i.e. 
    not just using HTTP.
    
    RW: There has been no analysis.
    
    EL: If we invite this into the WG we will start working on it. I want to 
    make sure before we do this. Before we do this, I want to see 
    sufficient well-spread interest in this.  If only 1 person wants to do 
    this, they can experiment all they want without WG involvement.
    
    PF: I agree with your concerns concerning new bindings. Regarding 
    whether the transport binding is part of the charter. I will require a 
    review by the WG or mailing list if the WG doesn't exist.  The mailing list 
    can not go away if the WG dies. I hope the WG winds up within 6 months. You 
    will still do the review, it doesn't need to be in the charter. 
    Milestones/Deliverables need to change.
    
    RS: The document can independently proceed, and the IESG reviews it?
    
    PF: Exactly. It wont be stopped by the WG if it is not in the 
    deliverables. The WG/ML will still need to review it.
    
    EL: The IETF will not get in the way of this. I'm not saying that we are 
    going to kill this by not putting it in the WG. What I am after is how many 
    people are willing to commit time and resources that would indicate it 
    should be a WG item?
    
    RW: If you're looking for low hanging fruit for a second transport 
    implementation, this is it. For me to implement this would take all of a 
    day. It is just not a big deal.
    
    JP: Just one thing about that - i think it is a reasonable barrier to 
    entry to insist on finding a few implementors to make it a WG item. I 
    think this is the wrong forum to ask this question.
    
    EL: This will go to the mailing list.
    
    PF: One thing, BTW, I take the constraint of transport protocols as an 
    action item.
    
    JP: I definitely think it should not be characterized as a L4 
    protocol.
    
    EL: The other item on the agenda, is the SMTP draft. This is an case of why 
    my (as chair) skepticism towards new documents has been rising over the 
    years.  People have said they are all for an SMTP transport, with 3-4 
    volunteers.  Finally someone wrote a document. Further discussion has not 
    happened as the author is unavailable at this time. SMTP is something 
    people have liked over time.  Are there people who would like to 
    implement SMTP transport?
    
    OK, No hands showing here.  This will go back to the ML, but it could be we 
    don't pursue this.  Anyone think this is a great loss?
    
    No. Ok. We may ask to remove a milestone. We only have that and one other 
    milestone.
    
    EL: Next item on the agenda is the only other WG document we have, that 
    Scott has, the guidelines for extending EPP. I would like to see this 
    document mature very quickly.
    
    (Side note: We also need to discuss the milestones, some have been done and 
    subsequently dropped.)
    
    SH: This doc was first published a few months ago, as a result of some 
    screwy ways of extending the protocol in some independent documents. The 
    only comments I have received is from Ed, there has been very little 
    discussion otherwise. I wanted some WG discussion before 
    implementing those comments.
    
    RW: This is the part where we talk about other docs?
    
    EL: I'd like to talk about the guidelines first?
    
    EL: The intent here is to give people a leg-up on extending EPP. The idea 
    came up about a year ago. How many people are implementors in this room?  
    OK, so it is the minority here. So in this case it is best discussed on 
    this list.
    
    EL: Ok, other documents.
    
    RW: I wanted to find out if there was interest in writing a BCP for 
    domain registries over EPP. Is this a good idea? It would be an 
    individual submission. It doesn't have to be a WG item. ... Sounds like a 
    resounding no.
    
    EL: Yeah I think it is not a WG item, but that doesn't stop you.
    
    EL: Next item is discussion on the future of the WG. It seems to me there 
    are some things still to work on. The IESG comments will require a little 
    bit of work, the SOAP is a consideration with more than 1 
    implementor in the room will want to take a look at, and we'll ask for 
    input from the ML. That could wind up as another item. It sounds like SMTP 
    will be tabled indefinitely or killed, not for the lack of interest but no 
    need to implement/interoperate. So, the extensions guidelines draft which 
    shouldn't be controversial, the IESG comments, and the SOAP draft - and I 
    think that is pretty much it.  If there isn't anything else, we can close 
    the meeting. I would like to get copies of the slides.
    
    PF: Wait - I was just looking for Allison. I asked her about UDP.
    Her experience has shown those using UDP do broken thing, so they want to 
    ban UDP. So that is the message back from Allison. So you need to make some 
    kind of statement and engage in discussion with the transport.
    
    EL: I might make a post to the ML that we will outlaw UDP, and see what 
    kind of flames we get.
    
    PF: I think we will also have a discussion within the IESG, if this kind of 
    requirement exists there needs to be some kind of statement.
    
    EL: OK, so I think we're done.
    
    Meeting Ends
    

    Slides

    EPP / SOAP