raw, uncooked notes from the meeting in Atlanta

[Edward Lewis <edlewis@arin.net>]

Here are, in an unprocessed form, the notes taken by our scribe, Kim 
Davies, in Atlanta.  Comment on them should go to me.  Since the 
notes are so comprehensive, I'm working on adding an "action item" 
intro to them.  I was going to do this before send this to the list, 
but it seems that there's already been calls to see this by those 
unable to attend the meeting in person.

~~~~~~~~~~~


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.

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.
..
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 Faelstroem (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 
summarises the issue
     that Eric has and pass it back to Allison. You could get Eric to 
do this. I dont think
     that the WG should declare rough concensus 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 thelist.
Simon ??: Many UDP protocols handle this like RPC implementations 
that do retries,
     backoffs 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 neednt 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 backoff algs, so over and over 
again people who
     use UDP fails.
RW: I dont feel it is appropriate to do this over UDP. I think that 
without a draft
     on this we should just move on.
??: Dont 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?
??: (not appropriate 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 dont 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: Summarise 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 concensus 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.

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 assocated
     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
     outsibe webpages. They do not have a workplan, 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 implemeneted,
     i dont 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 ext. mech.
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 elses 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 documents
     but we're not sure is applicable.
RS: I am happy to post the results from the Dulles WS, they are 
working on this and
     congniscent 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 rationable 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
     reaosnable 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 addressesd now?
RW: If you are not talking about privacy, I agree we dont 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 informaton 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 seperate.
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

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: Fromt he 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 iut.
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.

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 spec, 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
--------
JP: My slide is what i believe are the issues with the draft. Why 
would you want to
     implent 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 disucssed on the list that are unyet resolved. These 
are error codes, do
     we want to constract actual transport protocols used by soap, and 
how does this draft
     fit with existing deliverables od 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 numbner
     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 submitted it that he would like it as a WG item. That means 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 concensus 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 dont 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 IETF
     involvement.
PF: I agree with your concerns concerning new bindings. Regarding 
whether the transport binding
     is part of the charter. I wil 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 mahy 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 ML.

PF: One thing, BTW, I take the constraint of transport protocols as 
an action item.
JP: I definately think it should not be characterised as a L4 protocol.

EL: The other item on the agenda, is the SMTP draft. This is an 
example of skepticism
     raising 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 iwll 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 doc extend 
very quickly.
     (Sidenote: 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 
comemnts 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 idividual 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. So, the extensions guidelines draft which 
shouldn't be controversial,
     the iESG commnents, 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. 
Hwer 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.


ENDS
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                          +1-703-227-9854
ARIN Research Engineer