headers
Eric Brunner-Williams in Portland Maine | 1 Mar 2003 04:06

Re: our meeting slot in SF

I second Scott's suggestion, though in the general sense that getting some
substantive response from the IESG is in theory better than not getting a
substantive response, as I won't attend the face-to-face meeting of some
of the working group. I don't personally care if a member of the current
IESG contributes in an individual capacity, or if the IESG sits en banc,
during the scheduled face-to-face, though I appreciate those who've worked
on this set of drafts over the past two years who are present at this
meeting have a keener interest in the time and place some eventual disclosure
is offered.

Eric
Permalink | Reply | 0 comments |
headers
Ram Mohan | 1 Mar 2003 04:47

Re: our meeting slot in SF

amen

-ram
----- Original Message -----
From: "Hollenbeck, Scott" <shollenbeck <at> verisign.com>
To: "'Edward Lewis'" <edlewis <at> arin.net>; <ietf-provreg <at> cafax.se>
Sent: Friday, February 28, 2003 2:20 PM
Subject: RE: [ietf-provreg] our meeting slot in SF

> > THURSDAY, March 20, 2003
> > 0900-1130 Morning Sessions
> > APP     provreg   Provisioning Registry Protocol WG
> >
> >
> > Time to send in agenda suggestions...there are some obvious ones, I
> > won't disallow anyone from suggesting the obvious. ;)
>
> OK, then how about putting a slot in to get to the bottom of addressing
the
> IESG privacy comment -- assuming we can get the needed IESG members in the
> room to get it settled.
>
> -Scott-
>
>
Permalink | Reply | 0 comments |
headers
Eric Brunner-Williams in Portland Maine | 3 Mar 2003 13:21

Re: our meeting slot in SF


This is an issue-reminder, assuming that the IESG is responsive on the
privacy/data colleciton issue.

mappings over transports other than tcp.

The IESG claim is that commands cannot be reordered, which seems to be
reasonable for the transformational subset of epp commands, but not the
informational subset of epp commands, and this "resonability" appers to
be limited to com/net/org/info/biz/name transactions. Email is used, as
a transport for XML and BNF, elsewhere. Non-interoperation by intent is
an odd proposition, particularly by non-implementors and non-operators.

The IESG claim is also that applications protocols must provide congestion
control. I'm afraid this new requirement seems reflexive, not the product
of actual reflection on the deployment of epp. The publication protocols
commonly in use with registry provisioning include UDP, with absurdly large
difference in scale. Connectionism by design is an odd proposition too,
again by non-implementors and non-operators. It would be reasonable if this
work were within the ITU, which is both connectionist and mandarinist.

Just out of curiosity, since whois is such a problem, why on earth is the
inferred provisioning of social data to the com/net/org et alia whois
servers not _historic_? The US DCA is very, very, dead as an Agency of
Notice or Fashion.

Eric
Permalink | Reply | 0 comments |
headers
Edward Lewis | 3 Mar 2003 14:23

RE: FYI: EPP implementation by the Polish registry

At 14:52 -0800 2/28/03, Rick Wesson wrote:
>Ed,
>
>The private discussion the wg chairs have had with the IESG have prevented
>this group from moving forward; therefore I request all communication
>between the IESG and the wg chairs also CC the list.

???  "Prevented" is certainly not the right word.

>We have experenced 4 month delay because of this situation and it is
>unacceptable. We still are in a state of limbo.

Instead of trying to find fault, there should be an offering of 
suggestions.  All of the needed data exist in the archives.

>ed, please restate the issues, proposed solutions, wg consensus (if any
>appears evident) and iesg issues in a single concise e-mail to this wg
>so we can at the very least understand where we are in this process, and
>how we can move it forward.

The IESG comment given during the fall (message dated "Tue, 15 Oct 
2002 11:16:53 +0200"):

       why do domain/contact/.. not have granular information about privacy?

In a later discussion with Patrik, I was told that the EPP proposal 
did not meet the requirement in Section 8.4 of RFC 3375. ("See the 
MUST part of [1].")

There are three other inputs.  One from Jaap - a look at how privacy
(Continue reading)

Permalink | Reply | 0 comments |
headers
Hollenbeck, Scott | 3 Mar 2003 15:01
Picon
Favicon

RE: FYI: EPP implementation by the Polish registry

> I suppose this isn't the concise message you were hoping for, but I'd 
> rather the WG figure this out rather than have me spoon feed it to 
> you.  E.g., the comment that we don't meet the requirement above was 
> answered by me in a thread with an IESG member that ultimately went 
> no where.  (Maybe someone else needs to try.)

I sent a private message about the DCP requirement to Patrik last Thursday
or Friday.  He hasn't yet responded.

-Scott-
Permalink | Reply | 19 comments |
headers
Eric Brunner-Williams in Portland Maine | 3 Mar 2003 16:47

Re: FYI: EPP implementation by the Polish registry

> why do domain/contact/.. not have granular information about privacy?

Asked and answered.

1. Because operationally, policing at the session level is sufficient to
support persistent policing across multiple distinct objects, or support
single-object-session policing.

2. Because syntactically, if epp is to remain extensible, and xml-based,
adding attributes to elements is either pervasive, or specific. As this
WG lost the technical/social distinction with the expiry of Ross' draft,
we don't have a handy hook for being "specific", and "pervasive" makes
conditionally "private" even the data the registrants who have standing
to "privacy" under EU framework UNCONDITIONALLY SEEK TO PUBLISH.

3. Because semantically, it isn't simply contemporanious publication via
954 that is of issue, particularly in the EU, but also in the OEDC, and
potentially even the US. Also required is some mechanism to identify the
repurposing of registrant (and registrar) data, as bulk-access is a real
practice, with abuses. Also required is some mechanism to identify the
availability of collected registrant (and registrar) data for correction.
Also required is some mechanism to identify the duration that data is
held by the collector.

Adding these semantics to complexType elements would be complex, and has
no benefit over attaching the same semantics to aggregations of elements
that are NEVER DISAGGREGATED, aka "objects". There is little observed or
hypothetical inter-object disaggregation of policy that cannot be reasonably,
and scalably met, by bounding sessions by policy discontinuity.
(Continue reading)

Permalink | Reply | 18 comments |
headers
Edward Lewis | 3 Mar 2003 17:39

Re: FYI: EPP implementation by the Polish registry

At 10:47 -0500 3/3/03, Eric Brunner-Williams in Portland Maine wrote:
>Note Bene Chair:
>	1. IESG (Randy or Allison) asked and answered
>	2. IESG (Patrick) asked and answered
>	3. .NL asked and not responsive
>	4. .PL asked and not responsive
>	5. Newbie noises

I should respond to earlier parts of the mail, but I'll pick on this first.

As far as 1 & 2, the IESG has taken the first step the responsible 
guardian.  I have to admit, however, that the detail I have obtained 
from them has been insufficient to evaluate any proposed solution as 
being "the right one."  I do not dispute the spirit of the IESG 
comments, I just wish that the comments were supported by more 
substance, as could be provided by 3 & 4.

I cannot speak as to why 3 & 4 were not responsive.  But these 
categories represent an important voice that I think needs to be 
heard.  I was looking to such a constituency to give more information 
on what the IESG is hinting we need, but I haven't been able to 
introduce any discussion in this way.

(I should add that I am not so disappointed that 3 and 4 haven't 
responded, I am more disappointed that there haven't been other 
organizations of similar ilk saying anything at all.  Yes, that's a 
generalization - and the IETF is supposed to be individual 
participation, but the list needs to hear folks with knowledge of 
other environments to help pound out a solution to this issue.)
(Continue reading)

Permalink | Reply | 3 comments |
headers
Eric Brunner-Williams in Portland Maine | 3 Mar 2003 18:49

Re: FYI: EPP implementation by the Polish registry


> The latter case - "newbie" is rather derogatory term.

From <5nkf2vc69aamt50qla76umk9cscpun42ev <at> 4ax.com> 

> I am a newbie of this group and of the IETF WGs in general (please
> pardon me for anything inappropriate I might unvoluntarily do).
> However, I have been discussing DNS privacy issues extensively in the
> last years, so please allow me to give my point of view on the ongoing
> privacy discussion.

Note.

> Not addressing the privacy issue in the base protocol would likely
> imply that the service would often be deployed in real life without
> any means to achieve privacy protection.

Agree.

>                                           Unfortunately, the present
> lack of privacy protection in the WHOIS system is plainly illegal in
> many countries, and I don't think it's reasonable to think that this
> situation can go on for long without actual lawsuits starting to
> happen, both towards ccTLD and gTLD registries and registrars. 

Not relevant for a provisioning protocol. Specific to a particular
post-provisioned publication protocol, and none of us should be playing
lawyer on the net.

Its mechanism, mechanism, mechanism, mechanism, mechanism, mechanism and
(Continue reading)

Permalink | Reply | 2 comments |
headers
Hollenbeck, Scott | 3 Mar 2003 19:02
Picon
Favicon

RE: FYI: EPP implementation by the Polish registry

> >Does ((dnp==1 at .nl) == (dnp==1 at .com)) semantically 
> evaluate to 1, or 0?
> 
> The answer to this is a determining factor (to me at least) of 
> whether $dnp is in the base specification or in an extension.

As far as .com is concerned, I have no doubt that an extension will be
required even if we were to adopt the IESG's element tagging suggestion.
That being the case, my preference would be to put _all_ of the DNP syntax
and semantics into an extension (where the problem can be addressed as a
whole) while making the existing DCP element mandatory if that resolves the
privacy issue with the IESG.

-Scott-
Permalink | Reply | 503 comments |
headers
Edmon Chung | 3 Mar 2003 19:08

Re: our meeting slot in SF

I wonder if there might be interest in discussing the topic of IDN/EPP.  I
know that Scott's extension guideline already discussed briefly about it,
but it gave no provisions to the handling of character equivlancy
preparation (Charprep) issues and the related reserved variants and zone
variants management.

I dont have a draft yet, but am working on it.  I gave a presentation on the
issues and some experiments that we have done on a possible architecture for
handling the charprep recently (at the APRICOT) and it received very good
response.  I thought it would be a good idea to present it to the group and
get some feedback as I write my draft on the topic.

Edmon

----- Original Message -----
From: "Edward Lewis" <edlewis <at> arin.net>
To: <ietf-provreg <at> cafax.se>
Cc: <edlewis <at> arin.net>
Sent: Friday, February 28, 2003 1:35 PM
Subject: [ietf-provreg] our meeting slot in SF

> THURSDAY, March 20, 2003
> 0900-1130 Morning Sessions
> APP     provreg   Provisioning Registry Protocol WG
>
>
> Time to send in agenda suggestions...there are some obvious ones, I
> won't disallow anyone from suggesting the obvious. ;)
> --
> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
(Continue reading)

Permalink | Reply | 10 comments |

Gmane