last chance to comment

[Edward Lewis <edlewis@arin.net>]

I plan to send this in by Friday of this week.  I made some edits to 
the notes for clarification.  Let me know if anyone wants to suggest 
othter edits.

--------

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
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                          +1-703-227-9854
ARIN Research Engineer

last-verified-provreg-ietf55.#0

provreg55th.ppt