Subject: Re: IETF-51 WhoisFix BoF Announcement
From: "Ross Wm. Rader" <[email-masked]>
To: <[email-masked]>, <[email-masked]>, "Eric Brunner-Williams in Portland Maine" <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>
Date: Tue, 31 Jul 2001 14:46:40 -0400

Eric,

Correct me if my recollection is wrong, but the last go-round of this was
severely bogged down by a focus on the protocol specified in RFC 954 when in
fact the discussion was more suited to the concepts and facilities presented
in 1580 (starting on page 38). Is it the intent to focus on the latter than
the former this time around?

While I couldn't agree more that changes are due, it strikes me that
updating 954 may prove to be next to impossible because of the hidden
install base...

Sorry if this is off-topic for this list - I won't be in London to speak my
piece...

-rwr

----- Original Message -----
From: "Eric Brunner-Williams in Portland Maine" <[email-masked]>
To: <[email-masked]>; <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>
Sent: Tuesday, July 31, 2001 1:50 PM
Subject: IETF-51 WhoisFix BoF Announcement

>
> FYI,
>
> The agenda will be posted on the IETF-51 web site in a day or so.
>
> Thanks,
> Eric
> WHOISFix BoF co-chair
>
> ANNOUNCEMENT
> ------------
> Yet another attempt will be made to create a working group providing
> minimal enhancements to the WHOIS (port 43) service.
>
> This BOF will review a proposed charter and a proposed specification
> for enhancements. This round of effort will be marked by extremely
> narrow focus and extremely tight management to maintain that focus.
>
> The technical goals for the enhancement effort will be to:
> specify a common, structured query format,
> specify a means for server query redirection,
> specify server-server queries, and
> specify standardized whois structured response formats.
>
> Character set and data protection (privacy) issues are included in the
query
> and response format goals.

To: [email-masked], [email-masked]
cc: [email-masked], [email-masked]
Subject: IETF-51 WhoisFix BoF Announcement
Date: Tue, 31 Jul 2001 13:50:12 -0400
From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Sender: [email-masked]

FYI,

The agenda will be posted on the IETF-51 web site in a day or so.

Thanks,
Eric
WHOISFix BoF co-chair

ANNOUNCEMENT
------------
Yet another attempt will be made to create a working group providing
minimal enhancements to the WHOIS (port 43) service.

This BOF will review a proposed charter and a proposed specification
for enhancements. This round of effort will be marked by extremely
narrow focus and extremely tight management to maintain that focus.

The technical goals for the enhancement effort will be to:
	specify a common, structured query format,
	specify a means for server query redirection,
	specify server-server queries, and
	specify standardized whois structured response formats.

Character set and data protection (privacy) issues are included in the query
and response format goals.

To: Daniel Manley <[email-masked]>
cc: "[email-masked]'" <[email-masked]>, [email-masked]
Subject: Re: Data Collection Requirements 
Date: Tue, 31 Jul 2001 11:24:15 -0400
From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Sender: [email-masked]

Dan,

I'm glad you took the time to read Scott's note of the 5th, and you've
clearly given the issue some thought.

If you missed my reply to Scott, also of the 5th, it is in the archives.

Just to be clear, Scott proposed changing "data" to "social data", and
"policies" to "preferences".

Scott also reiterated his belief that data collection policy will be
signaled out-of-band, e.g., by contract.

Some minor remarks specific to your note:

> In terms of web sites, because of ... [baroque richness]
> But with registries and the limited (snip) data [leave as "data" for now]

Agreed, the P3P schema and vocabulary are a model, not the answer to be
applied thoughtlessly. That was part of my purpose in mentioning another
protocol which performs onward-transport of consumer social data. I gave
the reference in my reply to Scott on this list.

> EPP could define a configurable set of policies

Yup. Ditto for XRP, ...

> Each registry could set defaults ...

Yup.

> Registrars would be told of the settings ...

Yup. Scope is now registry-global. (registrars to resellers to reresellers ...)

> (via contracts and published policies of the regsitry)

That's one way. Out-of-band announcement. Optional. See your next.

> and could attempt to set global preferences on login (maybe with the login
> command or a separate command)

Yup. Amounts to negociation, over a fairly limited range of discreet values.
Scope is now registrar-global.

> For the sake of completeness, there could be a (policy):info command.

Yup. That's one way. Paren denotes s/preference/policy/

>  Each contact would also have privacy (policy) attached because ...

Yup. Scope is now registrant. Paren denotes s/preference/policy/

> I just don't think that (snip) data privacy with EPP registries should 
> be a big black cloud (snip).  There's limited data and 
> controlled audiences (registry/registrars) involved so the policies 
> surround that should be simple.

Yup. I've snip'd out the parts that aren't necessary to the core problem
of provisioning policy meta-data.

This leaves Scott's two changes, s/data/social &/, and s/policy/preference/.

Cheers,
Eric

Date: Mon, 30 Jul 2001 12:47:48 -0400
From: Daniel Manley <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: Re: Data Collection Requirements
Sender: [email-masked]

Just to give this topic a bit of a kick start before IETF 51...

I personally agree with Scott's suggested updates to the requirement:  

A generic protocol MUST provide services to identify social data use
preferences.

In terms of web sites, because of the wide array of web services and 
data requirements, P3P and the opposite requirement wording are more 
appropriate.  But with registries and the limited social data, EPP could 
define a configurable set of policies.  Each registry could set defaults 
or unchangeable settings based on contract agreements.  Registrars would 
be told of the settings (via contracts and published policies of the 
regsitry) and could attempt to set global preferences on login (maybe 
with the login command or a separate command).  For the sake of 
completeness, there could be a preference:info command.  Each contact 
would also have privacy preferences attached because each registrant 
might have different privacy needs (either via personal comfort level or 
geographical region, etc...).

I just don't think that social data privacy with EPP registries should 
be a big black cloud that P3P could make it.  There's limited data and 
controlled audiences (registry/registrars) involved so the policies 
surround that should be simple.

Dan

To: [email-masked]
Subject: (Repost) 51st IETF - Provisioning Registry Protocol WG (provreg)
Date: Fri, 27 Jul 2001 14:33:14 +0200
From: Jaap Akkerhuis <[email-masked]>
Sender: [email-masked]

I noticed a lot of complaints from he listserver about unknown
adresses, just after this was posted to the list. Just to make sure
that this actually went out, I decided to repost it.

	jaap

Provisioning Registry Protocol WG (provreg)

Wednesday, August 08 at 1530-1730
==================================

Hilton Rooms 1-6 (Multicast Room)

CHAIRS: Jaap Akkerhuis <[email-masked]>
        Ed Lewis <[email-masked]>

AGENDA:

The usual: bashing (the agenda) & document/wg status.........15 minutes
     Selection of minute taker
           (http://www.ietf.org/instructions/minutes.html)
     Requirements document status, comments from IESG
     The missing documents (e.g., mapping of EPP to BEEP)

OPP draft, comparison w/EPP and GRRP (James).................25 minutes
     http://www.ietf.org/internet-drafts/draft-jseng-provreg-opp-00.txt
     Discussion: How does this fit into WG plans?  Should this be admitted
     to the group?

Discussion on Data Collection Requirements (Scott)...........20 minutes
     http://www.ietf.org/internet-drafts/draft-ietf-provreg-grrp-reqs-02.txt
     http://www.cafax.se/ietf-provreg/maillist/2001-07/msg00002.html
     Discussion: a clarification of requirements generated by a dilemma
     in protocol design.

EPP drafts, outside deadlines................................20 minutes
     http://www.ietf.org/internet-drafts/draft-ietf-provreg-epp-04.txt
     http://www.ietf.org/internet-drafts/draft-ietf-provreg-epp-*-02.txt
     (See http://www.ietf.org/html.charters/provreg-charter.html)

XRP draft, comparison w/EPP and GRRP (Eric)..................25 minutes
     http://www.ietf.org/internet-drafts/draft-brunner-xrp-00.txt
     Discussion: How does this fit into WG plans?  Should this be admitted
     to the group?

Implementaion-to-date commentary (?).........................15 minutes
     Discussion: comments are sought on the state of implementations of
     the proposals.  (Volunteers sought.)
                                                            ============
                                                               2 hours

Other Items that may creep into the agenda (but haven't been allotted time
yet:

     The Definitions document
     http://www.ietf.org/internet-drafts/draft-ietf-provreg-dn-defn-01.txt
     Discussion: originally thought to accompany the requirements, but now
     having a separate document seems like overkill.  This may slip into
     document status (unless the author wishes to speak).

     Report from RIR's on provreg
     I've asked for the RIR viewpoint on Provreg matters, but didn't give
     the contact person much advance warning.  Hopefully we can hear from
     that group - if they have time to prepare.  If we do have a report,
     5 minutes could be knocked off the OPP and XRP items (as they are the
     longest).

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                NAI Labs
Phone: +1 443-259-2352                      Email: [email-masked]

You fly too often when ... the airport taxi is on speed-dial.

Opinions expressed are property of my evil twin, not my employer.

Date: Thu, 26 Jul 2001 08:33:08 -0700 (PDT)
From: Rick H Wesson <[email-masked]>
To: Edward Lewis <[email-masked]>
cc: James Seng/Personal <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: Re: Proposed agenda
Sender: [email-masked]

IMHO,

drafts should only be discussed at the meeting if there is some discussion
on the list. I've read the draft and feel that is completely out of scope
of our current work.

I hate seeing valuable discussion time taken up by drafts with only the
support of the author.

-rick

On Thu, 26 Jul 2001, Edward Lewis wrote:

> At 10:05 PM -0400 7/25/01, James Seng/Personal wrote:
> >No update was done to -00 and no intention to, since it is not relevant
> >to provreg as the co-chairs claims.
>
> For the record, the co-chairs have never made any judgement on the
> relevance of the document.  We have refused to make it a WG item in its
> current state, but would like to see it discussed at the meeting to see if
> it shows promise.
>
> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
> Edward Lewis                                                NAI Labs
> Phone: +1 443-259-2352                      Email: [email-masked]
>
> You fly too often when ... the airport taxi is on speed-dial.
>
> Opinions expressed are property of my evil twin, not my employer.
>
>

Date: Thu, 26 Jul 2001 10:30:26 -0400
To: [email-masked]
From: Edward Lewis <[email-masked]>
Subject: additional info for the agenda
Sender: [email-masked]

The URL for the IESG comments on GRRP is:
   http://www.cafax.se/ietf-provreg/maillist/2001-07/msg00000.html

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                NAI Labs
Phone: +1 443-259-2352                      Email: [email-masked]

You fly too often when ... the airport taxi is on speed-dial.

Opinions expressed are property of my evil twin, not my employer.

Date: Thu, 26 Jul 2001 10:16:45 -0400
To: [email-masked]
From: Edward Lewis <[email-masked]>
Subject: 51st IETF - Provisioning Registry Protocol WG (provreg)
Cc: [email-masked]
Sender: [email-masked]

Provisioning Registry Protocol WG (provreg)

Wednesday, August 08 at 1530-1730
==================================

Hilton Rooms 1-6 (Multicast Room)

CHAIRS: Jaap Akkerhuis <[email-masked]>
        Ed Lewis <[email-masked]>

AGENDA:

The usual: bashing (the agenda) & document/wg status.........15 minutes
     Selection of minute taker
           (http://www.ietf.org/instructions/minutes.html)
     Requirements document status, comments from IESG
     The missing documents (e.g., mapping of EPP to BEEP)

OPP draft, comparison w/EPP and GRRP (James).................25 minutes
     http://www.ietf.org/internet-drafts/draft-jseng-provreg-opp-00.txt
     Discussion: How does this fit into WG plans?  Should this be admitted
     to the group?

Discussion on Data Collection Requirements (Scott)...........20 minutes
     http://www.ietf.org/internet-drafts/draft-ietf-provreg-grrp-reqs-02.txt
     http://www.cafax.se/ietf-provreg/maillist/2001-07/msg00002.html
     Discussion: a clarification of requirements generated by a dilemma
     in protocol design.

EPP drafts, outside deadlines................................20 minutes
     http://www.ietf.org/internet-drafts/draft-ietf-provreg-epp-04.txt
     http://www.ietf.org/internet-drafts/draft-ietf-provreg-epp-*-02.txt
     (See http://www.ietf.org/html.charters/provreg-charter.html)

XRP draft, comparison w/EPP and GRRP (Eric)..................25 minutes
     http://www.ietf.org/internet-drafts/draft-brunner-xrp-00.txt
     Discussion: How does this fit into WG plans?  Should this be admitted
     to the group?

Implementaion-to-date commentary (?).........................15 minutes
     Discussion: comments are sought on the state of implementations of
     the proposals.  (Volunteers sought.)
                                                            ============
                                                               2 hours

Other Items that may creep into the agenda (but haven't been allotted time
yet:

     The Definitions document
     http://www.ietf.org/internet-drafts/draft-ietf-provreg-dn-defn-01.txt
     Discussion: originally thought to accompany the requirements, but now
     having a separate document seems like overkill.  This may slip into
     document status (unless the author wishes to speak).

     Report from RIR's on provreg
     I've asked for the RIR viewpoint on Provreg matters, but didn't give
     the contact person much advance warning.  Hopefully we can hear from
     that group - if they have time to prepare.  If we do have a report,
     5 minutes could be knocked off the OPP and XRP items (as they are the
     longest).

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                NAI Labs
Phone: +1 443-259-2352                      Email: [email-masked]

You fly too often when ... the airport taxi is on speed-dial.

Opinions expressed are property of my evil twin, not my employer.

Date: Thu, 26 Jul 2001 09:12:39 -0400
To: "James Seng/Personal" <[email-masked]>
From: Edward Lewis <[email-masked]>
Subject: Re: Proposed agenda
Cc: "Edward Lewis" <[email-masked]>, <[email-masked]>, <[email-masked]>
Sender: [email-masked]

At 10:05 PM -0400 7/25/01, James Seng/Personal wrote:
>No update was done to -00 and no intention to, since it is not relevant
>to provreg as the co-chairs claims.

For the record, the co-chairs have never made any judgement on the
relevance of the document.  We have refused to make it a WG item in its
current state, but would like to see it discussed at the meeting to see if
it shows promise.

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                NAI Labs
Phone: +1 443-259-2352                      Email: [email-masked]

You fly too often when ... the airport taxi is on speed-dial.

Opinions expressed are property of my evil twin, not my employer.

From: "Hollenbeck, Scott" <[email-masked]>
To: [email-masked]
Subject: RE: Proposed agenda
Date: Thu, 26 Jul 2001 07:08:08 -0400
Sender: [email-masked]

>-----Original Message-----
>From: James Seng/Personal [mailto:[email-masked]]
>Sent: Wednesday, July 25, 2001 10:06 PM
>To: Rick H Wesson; Edward Lewis
>Cc: [email-masked]; [email-masked]
>Subject: Re: Proposed agenda
>
>
>OPP is designed for some specific registry we doing for China and EPP is
>not able to meet the security requirements. The focus of OPP is on
>end-point authentication and authorization.

The statement "EPP is not able to meet the security requirements" caught my
attention.  One of the primary features of EPP is distinct layering so that
different types of service layers (such as additional security services) can
be defined with relative ease.  While it's true that there's nothing in the
current EPP specs that describes how transactions can be protected using (as
an example) XML digital signatures, the architecture is such that anyone can
write a draft describing such an additional service layer without having to
define a new protocol.

<Scott/>

From: "James Seng/Personal" <[email-masked]>
To: "Rick H Wesson" <[email-masked]>, "Edward Lewis" <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>
Subject: Re: Proposed agenda
Date: Thu, 26 Jul 2001 10:05:56 +0800
Sender: [email-masked]

> The XRP and OPP drafts are not on the prov-reg website at the IETF.

OPP was designed for Provreg and submitted as a provreg wg I-Ds but the
co-chairs have rejected it claiming there is no discussion on it.
(Wonder how would there be discussion if it is not accepted in the first
place).

OPP is designed for some specific registry we doing for China and EPP is
not able to meet the security requirements. The focus of OPP is on
end-point authentication and authorization.

> would the document authors mind posting the name and location of their
> drafts.

http://www.ietf.org/internet-drafts/draft-jseng-provreg-opp-00.txt

No update was done to -00 and no intention to, since it is not relevant
to provreg as the co-chairs claims.

-James Seng

> Ed, it would be 'nice' if you could list  all the relivant drafts on
the
> agenda so we would know what we have to read.
>
> Speciicly I'd like to know what OPP is...

Date: Wed, 25 Jul 2001 14:14:22 -0400
To: Rick H Wesson <[email-masked]>
From: Edward Lewis <[email-masked]>
Subject: Re: Proposed agenda
Cc: Edward Lewis <[email-masked]>, <[email-masked]>, <[email-masked]>
Sender: [email-masked]

At 12:10 PM -0400 7/25/01, Rick H Wesson wrote:
>Ed, it would be 'nice' if you could list  all the relivant drafts on the
>agenda so we would know what we have to read.

That's part of the boilerplating...;)

>
>Speciicly I'd like to know what OPP is...
>

There's a draft out there (from James Seng).  I do have the link (but it's
in the pocket of my other computer right now) and I'll include that in the
agenda I send to the secretariate (some time my tomorrow).

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                NAI Labs
Phone: +1 443-259-2352                      Email: [email-masked]

You fly too often when ... the airport taxi is on speed-dial.

Opinions expressed are property of my evil twin, not my employer.

Date: Wed, 25 Jul 2001 09:10:17 -0700 (PDT)
From: Rick H Wesson <[email-masked]>
To: Edward Lewis <[email-masked]>
cc: <[email-masked]>, <[email-masked]>
Subject: Re: Proposed agenda
Sender: [email-masked]

Ed,

The XRP and OPP drafts are not on the prov-reg website at the IETF.

would the document authors mind posting the name and location of their
drafts.

Ed, it would be 'nice' if you could list  all the relivant drafts on the
agenda so we would know what we have to read.

Speciicly I'd like to know what OPP is...

-rick

On Wed, 25 Jul 2001, Edward Lewis wrote:

> This is the first cut at the agenda.  I'd like to send this to the
> secretariate by tomorrow, so let me know if you want to make a serious
> alteration to it.
>
> BTW - don't worry about how "fixed" the agenda is - it can be changed on
> the fly.
>
> 0) The usual: bashing & document/wg status......................15 minutes
> 0.1) Requirements document status, comments from IESG
> 0.2) Missing documents (e.g. mapping of EPP to BEEP)
> 1) OPP draft, comparison w/EPP and GRRP (James).................25 minutes
> 2) Discussion on Data Collection Requirements (Scott)...........20 minutes
> 3) EPP drafts, outside deadlines................................20 minutes
> 4) XRP draft, comparison w/EPP and GRRP (Eric)..................25 minutes
> 5) Implementaion-to-date commentary (?).........................15 minutes
>                                                                ============
>                                                                   2 hours
>
> PS - I'll add the agenda boilerplate later...
>
> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
> Edward Lewis                                                NAI Labs
> Phone: +1 443-259-2352                      Email: [email-masked]
>
> You fly too often when ... the airport taxi is on speed-dial.
>
> Opinions expressed are property of my evil twin, not my employer.
>
>

Date: Wed, 25 Jul 2001 11:33:31 -0400
To: [email-masked]
From: Edward Lewis <[email-masked]>
Subject: Proposed agenda
Cc: [email-masked], [email-masked]
Sender: [email-masked]

This is the first cut at the agenda.  I'd like to send this to the
secretariate by tomorrow, so let me know if you want to make a serious
alteration to it.

BTW - don't worry about how "fixed" the agenda is - it can be changed on
the fly.

0) The usual: bashing & document/wg status......................15 minutes
0.1) Requirements document status, comments from IESG
0.2) Missing documents (e.g. mapping of EPP to BEEP)
1) OPP draft, comparison w/EPP and GRRP (James).................25 minutes
2) Discussion on Data Collection Requirements (Scott)...........20 minutes
3) EPP drafts, outside deadlines................................20 minutes
4) XRP draft, comparison w/EPP and GRRP (Eric)..................25 minutes
5) Implementaion-to-date commentary (?).........................15 minutes
                                                               ============
                                                                  2 hours

PS - I'll add the agenda boilerplate later...

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                NAI Labs
Phone: +1 443-259-2352                      Email: [email-masked]

You fly too often when ... the airport taxi is on speed-dial.

Opinions expressed are property of my evil twin, not my employer.

From: "Hollenbeck, Scott" <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: Date-time Representations
Date: Tue, 17 Jul 2001 08:46:10 -0400
Sender: [email-masked]

I just found text in the EPP drafts that incorrectly describes how date-time
values may be represented.  The current text:

"Both extended and truncated date and time forms defined in [ISO8601] MAY be
used, though a server SHOULD use one form or the other consistently."

Prompted by a last call reminder on the IMPP mailing list I took another
look at ISO 8601 and the XML Schema specs and found that XML Schema
specifically requires use of the extended date-time form [1].  What this
really means is that separators are REQUIRED between the various fields in
the date-time value such that this representation is valid:

2002-06-08T22:00:00.0Z

and this one is invalid:

20020608T220000.0Z

I'll change the text in the next edition of the drafts to note this
requirement:

"The extended date-time form defined in [ISO8601] MUST be used to represent
date-time values.

<Scott/>

[1] http://www.w3.org/TR/xmlschema-2/#dateTime

Date: Wed, 11 Jul 2001 10:20:06 -0400
To: [email-masked]
From: Edward Lewis <[email-masked]>
Subject: Agenda items so far
Cc: [email-masked]
Sender: [email-masked]

Here are the items collected so far, and in a rough order.  This won't be
final until the week before the meeting (technically, an ietf agenda isn't
final until the meeting is over ;) ).  This list is sent to draw other
items from other folks.

Agenda items to date:

0) The usual: bashing & document/wg status
0.1) Requirements document status, comments from IESG
0.2) Missing documents (e.g. mapping of EPP to BEEP)
1) Discussion on Data Collection Requirements (Scott)
2) XRP draft (Eric)
3) Comparison of XRP and EPP (Eric)
4) Implementaion commentary (?)

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                NAI Labs
Phone: +1 443-259-2352                      Email: [email-masked]

You fly too often when ... the airport taxi is on speed-dial.

Opinions expressed are property of my evil twin, not my employer.

From: "Hollenbeck, Scott" <[email-masked]>
To: "'Daniel Manley'" <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: RE: Comments on new drafts...
Date: Wed, 11 Jul 2001 09:24:21 -0400
Sender: [email-masked]

Many thanks, I'll add these to the list.

<Scott/>

>-----Original Message-----
>From: Daniel Manley [mailto:[email-masked]]
>Sent: Wednesday, July 11, 2001 9:16 AM
>To: [email-masked]
>Cc: [email-masked]; [email-masked]
>Subject: Re: Comments on new drafts...
>
>
>Hi Scott,
>Larry Yin and I have found a few other "bugs" with the new drafts:
>
>in draft-ietf-provreg-epp-04.txt  epp schema section
>   original:        <pattern value="[1-9].[0-9]"/> 
>   should be:       <pattern value="[1-9]\.[0-9]"/>
>
>in draft-ietf-provreg-epp-host-02.txt, around line 641, 
>there's a roid tag between the unpec and trid tags.  I think 
>it probably should not be there at all.
>
>Thanks,
>Dan

Date: Wed, 11 Jul 2001 09:16:14 -0400
From: Daniel Manley <[email-masked]>
To: [email-masked]
CC: [email-masked], [email-masked]
Subject: Re: Comments on new drafts...
Sender: [email-masked]

Hi Scott,
Larry Yin and I have found a few other "bugs" with the new drafts:

in draft-ietf-provreg-epp-04.txt  epp schema section
   original:        <pattern value="[1-9].[0-9]"/> 
   should be:       <pattern value="[1-9]\.[0-9]"/>

in draft-ietf-provreg-epp-host-02.txt, around line 641, there's a roid tag between the unpec and trid tags.  I think it probably should not be there at all.

Thanks,
Dan

[email-masked] wrote:

>Hi,
>
>thanks for the new drafts. I found some minor issues though...
>
>
>1. In the host-02 draft (lines 921-924):
>.    <import namespace="urn:iana:xml:ns:epp-1.0com-1.0"
>.            schemaLocation="eppcom-1.0.xsd"/>
>.    <import namespace="urn:iana:xml:ns:epp-1.0-1.0"
>.            schemaLocation="epp-1.0.xsd"/>
>.
>.   I guess it should be "eppcom-1.0" (not "epp-1.0com-1.0") and "epp-1.0" (not
>.   "epp-1.0-1.0").
>
>
>2. In the epp-04 draft (lines 1418-1420):
>.    S:    <msgQ count="5"/>
>.    S:      <qDate>2000-06-08T22:00:00.0Z</qDate>
>.    S:    </msgQ>
>.
>.  The first line should not have the trailing "/"
>
>
>3. In the epp-04 draft (lines 2997-2998):
>.          <pattern value="
>.    144168    </restriction>
>.
>.  This was (erroneously?) changed from 
>.        <pattern value="\w{1,80}-\w{1,8}"/>
>.      </restriction>
>
>
>
>Regards,
>
>Asbjorn Steira
>Global Name Registry
>

From: "Hollenbeck, Scott" <[email-masked]>
To: "'Eric Brunner-Williams in Portland Maine'" <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>
Subject: RE: Data Collection Requirements 
Date: Tue, 10 Jul 2001 09:51:26 -0400
Sender: [email-masked]

>-----Original Message-----
>From: Eric Brunner-Williams in Portland Maine
>[mailto:[email-masked]]
>Sent: Friday, July 06, 2001 1:36 PM
>To: Hollenbeck, Scott
>Cc: 'Eric Brunner-Williams in Portland Maine'; [email-masked]';
>[email-masked]
>Subject: Re: Data Collection Requirements 
>
>
>Scott,
>
>Sure.
>
>Eric

Would it be possible to provide examples sooner rather than later so we can
have a chance to examine and understand them before the WG session in
London?

<Scott/>

Date: Mon, 9 Jul 2001 16:50:35 -0400
To: "[email-masked]'" <[email-masked]>
From: Edward Lewis <[email-masked]>
Subject: FWIW: time slot in London
Cc: [email-masked]
Sender: [email-masked]

I have a preliminary time slot for us in London.  Note that the preliminary
time for the Minneapolis meeting changed, so what I'm about to type below
is not guaranteed.  But in case folks want to make travel plans around it...

Wednesday, 1530-1730.  This is just prior to a dinner break and the open
plenary.

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                NAI Labs
Phone: +1 443-259-2352                      Email: [email-masked]

You fly too often when ... the airport taxi is on speed-dial.

Opinions expressed are property of my evil twin, not my employer.

Date: Mon, 9 Jul 2001 15:18:32 -0400
To: "[email-masked]'" <[email-masked]>
From: Edward Lewis <[email-masked]>
Subject: agenda, was Re: Data Collection Requirements
Cc: [email-masked]
Sender: [email-masked]

At 10:58 AM -0400 7/6/01, Eric Brunner-Williams in Portland Maine wrote:
>> This topic _is_ the existing agenda item that Ed referred to in his call for
>> agenda items
>
>Really? Good. I hadn't noticed what the (single) agenda item was in Ed's mail.
>Call me clue-deficient.

Scott suggested the item, I didn't include it in the call for (other) items...

Speaking of which, I've so far only had two suggestions for agenda items to
date.  I'll be assembling a proto-agenda this week, so speak up if you have
requests.

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                NAI Labs
Phone: +1 443-259-2352                      Email: [email-masked]

You fly too often when ... the airport taxi is on speed-dial.

Opinions expressed are property of my evil twin, not my employer.

To: "Hollenbeck, Scott" <[email-masked]>
cc: "'Eric Brunner-Williams in Portland Maine'" <[email-masked]>, "[email-masked]'" <[email-masked]>, [email-masked]
Subject: Re: Data Collection Requirements 
Date: Fri, 06 Jul 2001 13:35:43 -0400
From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Sender: [email-masked]

Scott,

Sure.

Eric

From: "Hollenbeck, Scott" <[email-masked]>
To: "'Eric Brunner-Williams in Portland Maine'" <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>
Subject: RE: Data Collection Requirements 
Date: Fri, 6 Jul 2001 11:47:30 -0400 
Sender: [email-masked]

>-----Original Message-----
>From: Eric Brunner-Williams in Portland Maine
>[mailto:[email-masked]]
>Sent: Friday, July 06, 2001 10:58 AM
>To: Hollenbeck, Scott
>Cc: 'Eric Brunner-Williams in Portland Maine'; [email-masked]';
>[email-masked]
>Subject: Re: Data Collection Requirements 
>
>
>Here is the DTD (circa fall 2000, so no Schema) we developed in the privacy
>working group dealing with onward transfer (p3p policy presumed at the
first
>reseller-like web site, maintained and with jurisdictional "record route".
>It is followed by the DTD (same date) defining the CPExchange P3P subset.
>Similar work last October for the http state management mechanism (cookies)
>was incorporated into P3P as "compact representations" at a late moment,
and
>I understand will be part of the MS IE offering -- that is, in-line DC
policy
>expressed in XML.

Can you share an example XML _instance_ that's appropriate in the _provreg_
protocol context?  I'd like to understand how this specifically applies to
contact registration, for example.

How do things work if the reseller doesn't consistently use a web interface
to collect data?

<Scott/>

To: "Hollenbeck, Scott" <[email-masked]>
cc: "'Eric Brunner-Williams in Portland Maine'" <[email-masked]>, "[email-masked]'" <[email-masked]>, [email-masked]
Subject: Re: Data Collection Requirements 
Date: Fri, 06 Jul 2001 10:58:14 -0400
From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Sender: [email-masked]

> This topic _is_ the existing agenda item that Ed referred to in his call for
> agenda items

Really? Good. I hadn't noticed what the (single) agenda item was in Ed's mail.
Call me clue-deficient.

Folly is a stong word. I know I mentioned this at the San Diego meeting, and
on the (unfortunately collided provreg and whois lists last spring), but the
CPExchange (non-IETF) industry standard literally incorporates the P3P vocab.

Here is the DTD (circa fall 2000, so no Schema) we developed in the privacy
working group dealing with onward transfer (p3p policy presumed at the first
reseller-like web site, maintained and with jurisdictional "record route".
It is followed by the DTD (same date) defining the CPExchange P3P subset.
Similar work last October for the http state management mechanism (cookies)
was incorporated into P3P as "compact representations" at a late moment, and
I understand will be part of the MS IE offering -- that is, in-line DC policy
expressed in XML.

Sorry about the line length, and this is simply an example in a similar
problem domain (onward transfer of data similar to "social data"), not
the only way to incorporate data collection practices metadata with data,
if for no other reason than the CPExchange group was _very_ US-centric.

Eric

<!-- CPEXMLv1PRIVacy Information - Customer Profile Exchange XML Privacy category data
include file. This file depends on:
.........cpexmlv1p3pv1.dtd        CPExchange P3P subset
.........cpexmlv1types.dtd        XML Schema and CPExchange Types
.........cpexmlv1sup.dtd          CPExchange Support category
To use this file, declare this file and the listed files as ENTITYs. Include the listed
files in the order shown, followed by this file.

To incorporate the elements in this file into a higher level document structure, the
root, (or some other) element of the new document should include the CPEXMLv1PRIV
ENTITY that lists the top level elements in this file.

To restrict what elements can appear in a ControlGroup, the "templates" and "instances"
ENTITYs can be redefined before including this file.
-->

<!--  define hierarchies of classes where any class may be used (e.g.used polymorphically) -->
<!ENTITY % anyJurisdictionDeclaration " jurisdictionSpecification | jurisdictionReference">

<!-- the following ENTITY should be included in the document root element, or some other element -->
<!ENTITY % CPEXMLv1PRIV " privacyHeader?, controlGroup*">

<!-- define the individual classes with their properties -->

<!-- The templates and instances entities should be overridden in higher level dtds to restrict the elements that can appear in a ControlGroup -->
<!ENTITY % templates " ANY">
<!ENTITY % instances " ANY">
<!ENTITY % ControlGroup " templates?, instances">
    <!-- properties -->
        <!ELEMENT templates %templates;>
        <!ELEMENT instances %instances;>
<!ELEMENT controlGroup (%ControlGroup;)>

<!ENTITY % PrivacyHeader " sourceExchangePartner,recipientExchangePartner,jurisdictionDeclarations, privacyDeclarations">
    <!-- properties -->
        <!ELEMENT jurisdictionDeclarations ((%anyJurisdictionDeclaration;)*)>
        <!ELEMENT privacyDeclarations (privacyDeclaration*)>
<!ELEMENT privacyHeader (%PrivacyHeader;)>

<!ENTITY % ExchangePartner " identifier, identifierType">
    <!-- properties -->
        <!ELEMENT identifier (%string;)>
        <!ELEMENT identifierType (%OpenEnum;)>
            <!ATTLIST identifierType enumtype (ExchangePartnerIdentityTypeEnum) "ExchangePartnerIdentityTypeEnum">
<!ENTITY % ExchangePartnerAttrs " controllingJurisdictionIdrefs IDREFS #IMPLIED">
<!ELEMENT sourceExchangePartner (%ExchangePartner;)>
        <!ATTLIST sourceExchangePartner %ExchangePartnerAttrs;>
<!ELEMENT recipientExchangePartner (%ExchangePartner;)>
        <!ATTLIST recipientExchangePartner %ExchangePartnerAttrs;>

<!ENTITY % JurisdictionDeclaration "">
<!ENTITY % JurisdictionDeclaractionAttrs " eid ID #REQUIRED">

<!ENTITY % JurisdictionSpecification " %PropertyContainer;, countryCode? ">
    <!-- properties -->
<!ELEMENT jurisdictionSpecification (%JurisdictionSpecification;)>
     <!ATTLIST jurisdictionSpecification %JurisdictionDeclaractionAttrs;>

<!ENTITY % JurisdictionReference " specificationUrl ">
    <!-- properties -->
        <!ELEMENT specificationUrl (%uriReference;)>
<!ELEMENT jurisdictionReference (%JurisdictionReference;)>
     <!ATTLIST jurisdictionReference %JurisdictionDeclaractionAttrs;>

<!ENTITY % PrivacyControl "">
<!ENTITY % PrivacyControlAttrs " eid ID #REQUIRED">

<!ENTITY % PrivacyDeclaration " ACCESS,PURPOSE,RETENTION">
<!ELEMENT privacyDeclaration (%PrivacyDeclaration;)>
    <!ATTLIST privacyDeclaration %PrivacyControlAttrs;>

<!-- CPEXMLv1P3Pv1 Information - Customer Profile Exchange information used from P3P Version 1. This file has no dependencies on other files.
       
To use this file, declare this file as an ENTITY and include it. 

To incorporate the elements in this file into a higher level document structure, the
root, (or some other) element of the new document should include the elements as 
desired. This file imposes no structure on the use of these elements.
-->

<!-- beginning of P3P definitions -->
<!--  *********** ACCESS ***********  -->
<!ELEMENT ACCESS (nonident
    | ident_contact
    | other_ident
    | contact_and_other
    | all
    | none)>
<!ELEMENT nonident EMPTY>
<!ELEMENT ident_contact EMPTY>
<!ELEMENT other_ident EMPTY>
<!ELEMENT contact_and_other EMPTY>
<!ELEMENT all EMPTY>
<!ELEMENT none EMPTY>

<!--  *********** PURPOSE ***********  -->
<!ELEMENT PURPOSE ((current
    | admin
    | develop
    | contact
    | customization
    | tailoring
    | individual-analysis
    | individual-decision
    | pseudo-analysis
    | pseudo-decision
    | historical
    | telemarketing
    | other-purpose)+,
    EXTENSION*)>
<!ELEMENT current EMPTY>
<!ELEMENT admin EMPTY>
<!ELEMENT develop EMPTY>
<!ELEMENT contact EMPTY>
<!ELEMENT customization EMPTY>
<!ELEMENT tailoring EMPTY>
<!ELEMENT individual-analysis EMPTY>
<!ELEMENT individual-decision EMPTY>
<!ELEMENT pseudo-analysis EMPTY>
<!ELEMENT pseudo-decision EMPTY>
<!ELEMENT historical EMPTY>
<!ELEMENT telemarketing EMPTY>
<!ELEMENT other-purpose (#PCDATA)>

<!--  *********** RETENTION ***********  -->
<!ELEMENT RETENTION ((no-retention
    | stated-purpose
    | legal-requirement
    | indefinitely
    | business-practices),
    EXTENSION*)>
<!ELEMENT no-retention EMPTY>
<!ELEMENT stated-purpose EMPTY>
<!ELEMENT legal-requirement EMPTY>
<!ELEMENT indefinitely EMPTY>
<!ELEMENT business-practices EMPTY>

<!--  *********** RECIPIENT ***********  -->
<!ELEMENT RECIPIENT ((ours
    | same
    | other-recipient
    | delivery
    | public
    | unrelated)+,
    EXTENSION*)>
<!ELEMENT ours EMPTY>
<!ELEMENT same EMPTY>
<!ELEMENT other-recipient EMPTY>
<!ELEMENT delivery EMPTY>
<!ELEMENT public EMPTY>
<!ELEMENT unrelated EMPTY>

<!--  *********** EXTENSION ***********  -->
<!ELEMENT EXTENSION (#PCDATA)>
<!ATTLIST EXTENSION
     optional (yes | no) "yes" >

<!-- end of P3P definitions --

From: "Hollenbeck, Scott" <[email-masked]>
To: [email-masked]
Subject: RE: draft-ietf-provreg-grrp-reqs-02.txt
Date: Fri, 6 Jul 2001 08:22:03 -0400 
Sender: [email-masked]

>-----Original Message-----
>From: Patrik Fältström [mailto:[email-masked]]
>Sent: Monday, July 02, 2001 1:37 PM
>To: Jaap Akkerhuis; Ed Lewis; Scott Hollenbeck
>Cc: [email-masked]
>Subject: draft-ietf-provreg-grrp-reqs-02.txt
>
>
>The IESG have discussed the document draft-ietf-provreg-grrp-reqs-02.txt.

[snip]

I'm working on making changes to address the comments sent by Patrik, all of
which are pretty straight-forward.  Some coordination is required with the
dns* WGs to address the glue-related comments, but that's in progress and
going well.

I'd like to hold off on publishing a new version of the document until the
IESG comments have been addressed and we've had a chance to discuss the data
collection/use topic raised yesterday.  If we can get a good discussion
going, it might be possible to get a new version of the document out before
the I-D cut-off.  In the absence of pre-London mailing list discussion or
consensus we can take it up at IETF-51, describe the discussion on the
mailing list, and go from there.

<Scott/>

From: "Hollenbeck, Scott" <[email-masked]>
To: "'Eric Brunner-Williams in Portland Maine'" <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>
Subject: RE: Data Collection Requirements 
Date: Thu, 5 Jul 2001 22:19:33 -0400 
Sender: [email-masked]

> Let's have a discussion of data collection policies and discuss P3P and
how
> to specify reseller/registrar/registry data collection policies on the
agenda
> for London.

This topic _is_ the existing agenda item that Ed referred to in his call for
agenda items.  There's certainly room for discussion between now and then,
though, especially for folks who might not be going to London.

I for one would find it very helpful to see concrete examples of XML
instances specifying data collection policies that demonstrate the folly of
my concern with the current requirement text.

<Scott/>

To: "Hollenbeck, Scott" <[email-masked]>
cc: "[email-masked]'" <[email-masked]>, [email-masked]
Subject: Re: Data Collection Requirements 
Date: Thu, 05 Jul 2001 19:14:07 -0400
From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Sender: [email-masked]

Scott,

The current requirement in 8.4 [1] is:

	A generic protocol MUST provide services to identify data
	collection policies.

There is a MUST (manditory to implement) and a how "identify" (annouunce,
communicate, convay, ... and a what "policies".

The proposed change is:

	A generic protocol MUST provide services to identify
	social data use preferences.

There is a MUST (manditory to implement) and a how "identify" (annouunce,
communicate, convay, ... and a what "preferences", with a qualification
that the only data subject to this M2I requirement is "social".

Comment.

The issue was not identified in the IESG comments of 2 July (via Patrik).

Discussion I (scope: data vs social data)

"Social data" is defined [1], and [2] in the context of "thick" and "thin
models of dns name registries. A two-valued taxonomy of data transit and
repository models is not "generic", merely familiar.

In the existing context of [1], if the mechanism is sufficient to identify
the policies (note: not preferences) under which social data was collected,
and the policies for technical data are no more difficult to specify and
implement interoperably than those for social data, no apparent necessity
exists for declining to provide a mechanism to policy technical data.

Example technical data specific use case:

	provision object type == dns name, value == bar,
	in any registry of type dns name,
	except those not blackholing spammers, or unsigned, or ending in
	a stoplist (e.g., repurposed ccTLDs such as ".tv", ".bz" or ".md")

People can substitute their own zone file specific properties for the two
I picked out of my hat. Given the possibility of technical data specific
data collection policy, the necessity for precluding it in a generic protocol
is missing. 

Discussion II (substance: registry vs unknown actor)

Section 7.5 Extensibility [3] reads:

	The protocol MUST provide an optional field within all commands
	whose format and use will be controlled by individual registry
	policy.

The original is consistent with this. The proposed change is not. Registries
are not, under draft-ietf-provreg-grrp-reqs-02.txt, obliged to service those
registration requests which are inconsistent with Registry policy, other than
to generate some form of error response.

Whatever "preferences" are, they are not policies of the registry, and to
sensibly harmonize 7.5 [3] with something that isn't a registry policy, a
change to 7.5 [3] is required, or an additional Extensibility subsection
added which expresses a M2I requirement for all commands whose format and
use will be controlled by the preference and its originator (thing and actor
still TBD).

People can insert their own idea of who might be have a preference, it is
simply necessary that whoever that actor is, it is _incapable_ of binding
the registry to service its request. It isn't the registry, and it isn't
any originating or transit data collector, each of whom is likewise not
obliged to service those registration (transit) requests inconsistent with
their own respective policies, and incidently, fall outside the scope of
draft-ietf-provreg-grrp-reqs-02.txt.

Discussion II (substance: policy vs preference)

Contained in the next section. Sorry, I didn't write this top-to-bottom.

Discussion III (response to motivating comments)

Scott states two questions (which I've modified slightly to make them
symmetric):

	1. is our need to provide a way for a contact to describe the
	data it originates and what use of the data it authorizes 
	2. is our need to provide a way for a registry to describe the
	data it collects and what use of the data it authorizes

Scott suggests we need to solve the former, and not the latter. I differ.

In the P3P model, the problem of expressing user preferences, at least in
a form more general than in a single browser, is via APPEL, a language for
preferences. In the P3P model, the problem of expressing site data collection
practices, at least in a form more general than in a single web site, is via
P3P, a language for expressing data collection practices.

The first question involves a party other than a registry and a registrar
(and a resellers), to wit, a registrant. Therefore it is out of scope for
this requirements draft, and for the associated protocol(s).

The second question (as posed by Scott, and here extended by myself from
"a registry" to "an entity engaged in onward transfer of registrant data,
and a registry") involves only parties in the reseller/registry/registrar
set of entities. This is within the scope for this requirements draft, as
well as the associated protocol(s).

Scott's reading of the requirement I wrote is correct:

> As I read this requirement, it refers to a registry's data collection
> policies.  This is consistent with the way P3P is described by the W3C ("The
> Platform for Privacy Preferences Project (P3P) enables Web sites to express
> their privacy practices in a standard format that can be retrieved
> automatically and interpreted easily by user agents." [P3P]).

We are not however, as Scott continues, applying P3P by substitution, and
attempting to figure out what the Generic Registry Registrar Protocol
requirements would look like if it were a Generic HTTP Protocol requirement.
Rather, we are applying a model of data collection policy announcement to
each of the entities (thick or thin models) involved in onward transfer of
data, which are within the scope of the grrp draft. A P3P derived vocabulary
happens to be the best available tool at the moment that is consistent with
XML as the specification language [4].

This approach was also used in CPExchange version 1.0 [3].

A distinct, and previously mentioned issue is whether there actually is any
requirement for in-band data collection policy announcement. One line of
thought is that privacy has no place in the name (or address) space. Another
is that off-line contract is a sufficient mechanism to enable policy. I'm
sure there are others in addition to these to, and Scott only mentioned the
second of these. However, where interoperable standard mechanism is absent,
there is no possibility of interoperable standard policy. If we don't do the
first, we can't do the second. Maybe the American Bar Association can, or
ICANN, but the IETF simply cannot. Additionally, contract doesn't scale, and
there may be more than seven name registries and seventy name registrars in
the requirements space -- I think there is.

An even longer-winded explanation, neh?

Let's have a discussion of data collection policies and discuss P3P and how
to specify reseller/registrar/registry data collection policies on the agenda
for London.

Eric

References:
[1] draft-ietf-provreg-dn-defn-01.txt, Rader, at lines 167 and 177.
[2] draft-ietf-provreg-grrp-reqs-02.txt, Hollenbeck, at lines 202 and 206,
section 1.1 Definitions, Acronyms, and Abbreviations, and first used
in 3.4.2 Object Registration, lines 482, and subsequently.
and subsequently
[3] http://www.cpexchange.org/standard/cpexchangev1_0F.zip
[4] draft-ietf-provreg-epp-04.txt, at line 38.

[P3P] http://www.w3.org/TR/P3P/#Introduction

From: "Hollenbeck, Scott" <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: Data Collection Requirements
Date: Thu, 5 Jul 2001 08:42:22 -0400 
Sender: [email-masked]

While we're back in the requirements document to address the comments
received from the IESG, I'd like to address another requirements topic: data
collection requirements as described in section 8.4, specifically the last
sentence of 8.4-[1]:

"A generic protocol MUST provide services to identify data collection
policies."

I've been struggling with the protocol design aspects of this requirement,
and have spent a considerable amount of time reviewing the W3C's P3P work to
see how it might be useful as originally suggested by Eric Brunner-Williams.
Here's my dilemma:

As I read this requirement, it refers to a registry's data collection
policies.  This is consistent with the way P3P is described by the W3C ("The
Platform for Privacy Preferences Project (P3P) enables Web sites to express
their privacy practices in a standard format that can be retrieved
automatically and interpreted easily by user agents." [1]).

I'm not convinced that this is the problem we should be trying to solve.
Substitute "registries" for "Web sites" and "registrars" or "clients" for
"user agents", and what we have is a requirement for a registry to describe
the data it collects and what it might do with that data.  I know we've
touched on this before, but I'm convinced that this policy information will
be documented in agreements or contracts between registry and client.  The
legal ties between the communicating parties may not exist in the web world,
so I can understand how it makes sense for a web server to describe it's
data collection policies to web surfers.  However, the web user model isn't
the user model for GRRP, so I think we have this requirement somewhat
backwards.

We don't currently have a requirement to provide features to express how
social data may be used.  As I've struggled with the current requirement,
I've continually come back to two questions: is our need to provide a way
for a contact to express how their data (such as address, telephone, etc.)
may be used, or is our need to provide a way for a registry to describe the
data it collects and what it does with the data.  I really think the problem
we need to solve is the former, and not the latter.

Anyway, that long-winded explanation leads to a suggestion that we reword
the last sentence of 8.4-[1] to something like this:

"A generic protocol MUST provide services to identify social data use
preferences."

<Scott/>

[1] http://www.w3.org/TR/P3P/#Introduction

Date: Wed, 4 Jul 2001 08:35:05 -0400
To: "[email-masked]'" <[email-masked]>
From: Edward Lewis <[email-masked]>
Subject: IETF 51 Agenda Items
Cc: [email-masked]
Sender: [email-masked]

We have requested a meeting slot at the 51st IETF.  Now we need to have
something to talk about.

I have already received one agenda item, and am asking for others to
volunteer meeting content.

(For those on the list but not up on IETF activities, there's information
about the meeting at http://www.ietf.org/meetings/IETF-51.html)

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                NAI Labs
Phone: +1 443-259-2352                      Email: [email-masked]

You fly too often when ... the airport taxi is on speed-dial.

Opinions expressed are property of my evil twin, not my employer.

Date: Mon, 02 Jul 2001 10:37:29 -0700
From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= <[email-masked]>
To: Jaap Akkerhuis <[email-masked]>, Ed Lewis <[email-masked]>, Scott Hollenbeck <[email-masked]>
cc: [email-masked]
Subject: draft-ietf-provreg-grrp-reqs-02.txt
Sender: [email-masked]

The IESG have discussed the document draft-ietf-provreg-grrp-reqs-02.txt.

Summary:

The IESG find some issues regarding (1) the use of the term "TLD", (2) the
restrictions on use of NS and glue in zones and (3) the use of the term MAY
in the document.

Conclusion: A new document is needed after these issues are resolved. We
advice the wg/author to resolv issue (2) in close cooperation with the
DNSEXT and DNSOP wg's.

When a new version of the document is announced, please let me and rest of
IESG know explicitly.

In more detail:

(1) Use of the term TLD

In the following sections...

   1.1 (Definition of Registry)
   2.1 System Perspective
   2.2 System Functions
   2.4 Assumptions
   3.4.2 [5] (Where NS is registered)
   8.2 Operational Requirements [1] (Whether human intervention
       is needed or not)

...the document talk about about "TLD", when the registry function you
describe have nothing to do with whether we talk about a registry for a TLD
or any other domain further down in the tree. I know this have been brought
this up before on the mailing list, but we need to talk about it again.

You should remove the explicit notion of TLD and replace with other
wordings.

(2) Restrictions on glue and NS

In section 3.4.2 you have the following text:

  [3] The protocol MUST provide services to register name servers.  Name
  server registration MUST NOT be limited to a specific period of time.
  Name servers MUST be registered with a valid IPv4 or IPv6 address when
  a "glue record" is REQUIRED for domain delegation.  A name server MAY
  be registered with multiple IP addresses.  An IP address MAY be shared
  among multiple name servers using distinct server names.

  :

  [5] Name servers associated with a domain MAY be registered in a
  different domain or even in a TLD for which the registry is not
  authoritative.  This means that IP addresses for name servers whose
  domain name exists in another TLD MUST be registered only in the
  registry that is authoritative for the TLD of the name server.  Glue
  records (DNS "A" records) MUST only be created for DNS "NS" records
  for which the registry is authoritative.

Note that [3] talk about "NS is registered when a Glue is needed". [5] on
the other hand say that glue is only to be added when the NS is in a domain
for which the registry is authoritative.

Now, we can have the following theoretical setup:

  In the registry for the foo TLD:

    frotz.foo. IN NS ns.fizzle.bar.

  In the registry for the bar TLD:

    fizzle.bar. IN NS ns.frotz.foo.

[3] above say that glue must be added somewhere (it has to), but [5] say
that the glue can not be added to either of the zones. Everyone knows that
one should only add in a case which [5] describe, BUT also whenever one
find that a glue is needed (theoretical case above).

The IESG want the provreg wg to in close discussions with the DNSEXT and
DNSOP wg's resolve what the text and requirements should be. Should it be
described what can be done with DNS (theoretical example above), or should
we be more restrictive (all the way to "only one nameserver name per host
is allowed") to limit the amount of misconfigured nameservers out there?

(3) The use of the term MAY in this document

The IESG feel that the term MAY is describing the application which uses
this protocol and not the protocol itself, and therefore the term is used
in the wrong way. Example, if as it says a domain MAY have two nameservers
or more, then the protocol MUST be able to handle that case.

We ask you to go through all use of uppercase MUST/MAY etc in the document
and change so the uppercase words are really used for the protocol. If the
application / functionality is described, lowercase words should be used
(and the fact it describes the application should be more explicit).

   Patrik