[Gen-art] Assignments for Oct 22nd, 2009 Telechat
Hi all, Here's the link to the summary of assignments for the Oct. 22nd, 2009 telechat: http://www.softarmor.com/rai/temp-gen-art/reviewers-091022.html With the updated spreadsheets: http://www.softarmor.com/rai/temp-gen-art/gen-art.html http://www.softarmor.com/rai/temp-gen-art/gen-art-by-reviewer.html For your convenience, the review boilerplate template is included below. Note that reviews should ideally be posted to the gen-art mailing list by COB on Tuesday: http://www.alvestrand.no/ietf/gen/art/review-guidelines.html Mary. --- I have been selected as the General Area Review Team (Gen-ART) reviewer for this draft (for background on Gen-ART, please see http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html). Please wait for direction from your document shepherd or AD before posting a new version of the draft. Document: Reviewer: Review Date: IESG Telechat date: 22 Oct 2009 Summary: Major issues: Minor issues: Nits/editorial comments: ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] A *new* batch of IETF LC reviews - 15 Oct 2009
Hi all, Here's the link to the new LC assignments for this week: http://www.softarmor.com/rai/temp-gen-art/reviewers-091015-lc.html The assignments are captured in the spreadsheets: http://www.softarmor.com/rai/temp-gen-art/gen-art.html http://www.softarmor.com/rai/temp-gen-art/gen-art-by-reviewer.html The standard template is included below. Thanks, Mary. --- I have been selected as the General Area Review Team (Gen-ART) reviewer for this draft (for background on Gen-ART, please see http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html). Please resolve these comments along with any other Last Call comments you may receive. Document: Reviewer: Review Date: IETF LC End Date: IESG Telechat date: (if known) Summary: Major issues: Minor issues: Nits/editorial comments: ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
Re: [Gen-art] Gen-ART LC review ofdraft-ietf-vcarddav-carddav-09.txt
Hi Brian, --On October 16, 2009 9:01:43 AM +1300 Brian E Carpenter wrote: I'm happy with the proposed changes, as far as my review goes. I agree with Marc, it seems correct to verify such changes in normative requirements with the WG. Email has been sent to the WG list. -- Cyrus Daboo ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
Re: [Gen-art] Gen-ART LC review ofdraft-ietf-vcarddav-carddav-09.txt
I'm happy with the proposed changes, as far as my review
goes. I agree with Marc, it seems correct to verify such
changes in normative requirements with the WG.
Brian
On 2009-10-16 06:32, Marc Blanchet wrote:
> these changes are enough important that we must have wg review on this
> before proceeding further. I suggest we should bring this (SHOULD/MUST
> TLS) to the wg.
>
> Marc.
>
> Cyrus Daboo a écrit :
>> Hi Alexey,
>>
>> --On October 13, 2009 11:54:39 AM +0100 Alexey Melnikov
>> wrote:
>>
I would be happy with that; it's probably something to be checked with
the WG since it's a change in normative requirements.
>>> I wonder if this needs to be phrased as "Clients MUST implement TLS
>>> support, SHOULD use it"?
>>
>> I think MUST is too strong. There a situations where a client may
>> exist on a private network (e.g. a server farm with a carddav server
>> and a webapp accessing it) where there is no need for TLS, or they may
>> exist in an environment where some other form of security layer is
>> present (e.g. ipsec). Implementors of such clients should not be
>> burdening with implementing TLS if they don't need it.
>>
>> On the same lines,
>>
>> Clients MAY choose to warn users when they create address data in a
>> public address book, copy or move address data into public address
>> books, or change access privileges in such a way as to expose
>> address
>> data to unauthenticated users.
>>
>> Why isn't that a SHOULD?
>>
>>
> I am a little nervous about putting such a requirement on a client.
> First of all, what does it really mean to "warn" a user? An alert, an
> icon, a noise? Does it happen only the first time they do an
> action, or
> each time? SHOULD seems a little strong when the nature of the warning
> is really going to be implementation dependent.
>
> That said, if there is consensus for this change, it may be
> necessary to
> explain a little more what "warn" means.
>
>
Yes, that is a problem. I'm not a privacy expert, but it does seem like
something that could one day end up as bad news. ("XYZ Corporation
revealed private data for 27,000 customers, FCC investigation alleges.
We just followed the IETF standard, says XYZ spokesman.") I think it
needs a little thought.
>>> I think SHOULD is better here.
>>> And yes, I think some explanation of what "warns" mean is needed, as
>>> well
>>> as some possible description of "remember my answer" checkbox (or
>>> similar).
>>
>> OK, I can change that paragraph to
>>
>>Clients SHOULD warn users in an appropriate fashion when they copy or
>>move address data from a private address book to a shared address book
>>(one accessible by other authenticated users only) or public address
>>book (one accessible by unauthenticated users). Clients SHOULD provide
>>a clear indication as to which address books are private, shared or
>>public. Clients SHOULD provide an appropriate warning when changing
>>access privileges for a private or shared address book with data so as
>>to allow unauthenticated users access.
>>
>> Is that reasonable?
>>
>
>
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art
Re: [Gen-art] Gen-ART LC review ofdraft-ietf-vcarddav-carddav-09.txt
these changes are enough important that we must have wg review on this
before proceeding further. I suggest we should bring this (SHOULD/MUST
TLS) to the wg.
Marc.
Cyrus Daboo a écrit :
Hi Alexey,
--On October 13, 2009 11:54:39 AM +0100 Alexey Melnikov
wrote:
I would be happy with that; it's probably something to be checked with
the WG since it's a change in normative requirements.
I wonder if this needs to be phrased as "Clients MUST implement TLS
support, SHOULD use it"?
I think MUST is too strong. There a situations where a client may exist
on a private network (e.g. a server farm with a carddav server and a
webapp accessing it) where there is no need for TLS, or they may exist
in an environment where some other form of security layer is present
(e.g. ipsec). Implementors of such clients should not be burdening with
implementing TLS if they don't need it.
On the same lines,
Clients MAY choose to warn users when they create address data in a
public address book, copy or move address data into public address
books, or change access privileges in such a way as to expose
address
data to unauthenticated users.
Why isn't that a SHOULD?
I am a little nervous about putting such a requirement on a client.
First of all, what does it really mean to "warn" a user? An alert, an
icon, a noise? Does it happen only the first time they do an action, or
each time? SHOULD seems a little strong when the nature of the warning
is really going to be implementation dependent.
That said, if there is consensus for this change, it may be
necessary to
explain a little more what "warn" means.
Yes, that is a problem. I'm not a privacy expert, but it does seem like
something that could one day end up as bad news. ("XYZ Corporation
revealed private data for 27,000 customers, FCC investigation alleges.
We just followed the IETF standard, says XYZ spokesman.") I think it
needs a little thought.
I think SHOULD is better here.
And yes, I think some explanation of what "warns" mean is needed, as well
as some possible description of "remember my answer" checkbox (or
similar).
OK, I can change that paragraph to
Clients SHOULD warn users in an appropriate fashion when they copy or
move address data from a private address book to a shared address book
(one accessible by other authenticated users only) or public address
book (one accessible by unauthenticated users). Clients SHOULD provide
a clear indication as to which address books are private, shared or
public. Clients SHOULD provide an appropriate warning when changing
access privileges for a private or shared address book with data so as
to allow unauthenticated users access.
Is that reasonable?
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art
Re: [Gen-art] Gen-ART LC review ofdraft-ietf-vcarddav-carddav-09.txt
Cyrus Daboo wrote:
Hi Alexey,
--On October 13, 2009 11:54:39 AM +0100 Alexey Melnikov
wrote:
I would be happy with that; it's probably something to be checked with
the WG since it's a change in normative requirements.
I wonder if this needs to be phrased as "Clients MUST implement TLS
support, SHOULD use it"?
I think MUST is too strong. There a situations where a client may
exist on a private network (e.g. a server farm with a carddav server
and a webapp accessing it) where there is no need for TLS, or they may
exist in an environment where some other form of security layer is
present (e.g. ipsec). Implementors of such clients should not be
burdening with implementing TLS if they don't need it.
Leaving "client SHOULD use TLS" would be Ok with me, but the rest of
IESG might disagree.
So anyway, I've added this as an RFC Editor note.
On the same lines,
Clients MAY choose to warn users when they create address data in a
public address book, copy or move address data into public address
books, or change access privileges in such a way as to expose
address
data to unauthenticated users.
Why isn't that a SHOULD?
I am a little nervous about putting such a requirement on a client.
First of all, what does it really mean to "warn" a user? An alert, an
icon, a noise? Does it happen only the first time they do an
action, or
each time? SHOULD seems a little strong when the nature of the warning
is really going to be implementation dependent.
That said, if there is consensus for this change, it may be
necessary to
explain a little more what "warn" means.
Yes, that is a problem. I'm not a privacy expert, but it does seem like
something that could one day end up as bad news. ("XYZ Corporation
revealed private data for 27,000 customers, FCC investigation alleges.
We just followed the IETF standard, says XYZ spokesman.") I think it
needs a little thought.
I think SHOULD is better here.
And yes, I think some explanation of what "warns" mean is needed, as
well
as some possible description of "remember my answer" checkbox (or
similar).
OK, I can change that paragraph to
Clients SHOULD warn users in an appropriate fashion when they copy or
move address data from a private address book to a shared address book
(one accessible by other authenticated users only) or public address
book (one accessible by unauthenticated users). Clients SHOULD provide
a clear indication as to which address books are private, shared or
public. Clients SHOULD provide an appropriate warning when changing
access privileges for a private or shared address book with data so as
to allow unauthenticated users access.
Is that reasonable?
I like that. Added as an RFC Editor note.
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art
Re: [Gen-art] Gen-ART LC review ofdraft-ietf-vcarddav-carddav-09.txt
Hi Alexey,
--On October 13, 2009 11:54:39 AM +0100 Alexey Melnikov
wrote:
I would be happy with that; it's probably something to be checked with
the WG since it's a change in normative requirements.
I wonder if this needs to be phrased as "Clients MUST implement TLS
support, SHOULD use it"?
I think MUST is too strong. There a situations where a client may exist on
a private network (e.g. a server farm with a carddav server and a webapp
accessing it) where there is no need for TLS, or they may exist in an
environment where some other form of security layer is present (e.g.
ipsec). Implementors of such clients should not be burdening with
implementing TLS if they don't need it.
On the same lines,
Clients MAY choose to warn users when they create address data in a
public address book, copy or move address data into public address
books, or change access privileges in such a way as to expose address
data to unauthenticated users.
Why isn't that a SHOULD?
I am a little nervous about putting such a requirement on a client.
First of all, what does it really mean to "warn" a user? An alert, an
icon, a noise? Does it happen only the first time they do an action, or
each time? SHOULD seems a little strong when the nature of the warning
is really going to be implementation dependent.
That said, if there is consensus for this change, it may be necessary to
explain a little more what "warn" means.
Yes, that is a problem. I'm not a privacy expert, but it does seem like
something that could one day end up as bad news. ("XYZ Corporation
revealed private data for 27,000 customers, FCC investigation alleges.
We just followed the IETF standard, says XYZ spokesman.") I think it
needs a little thought.
I think SHOULD is better here.
And yes, I think some explanation of what "warns" mean is needed, as well
as some possible description of "remember my answer" checkbox (or
similar).
OK, I can change that paragraph to
Clients SHOULD warn users in an appropriate fashion when they copy or
move address data from a private address book to a shared address book
(one accessible by other authenticated users only) or public address
book (one accessible by unauthenticated users). Clients SHOULD provide
a clear indication as to which address books are private, shared or
public. Clients SHOULD provide an appropriate warning when changing
access privileges for a private or shared address book with data so as
to allow unauthenticated users access.
Is that reasonable?
--
Cyrus Daboo
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] review of draft-ietf-mmusic-connectivity-precon-06.txt
I have been selected as the General Area Review Team (Gen-ART) reviewer for this draft (for background on Gen-ART, please see http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html). Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-mmusic-connectivity-precon-06.txt Reviewer: Francis Dupont Review Date: 2009-10-12 IETF LC End Date: 2009-10-14 IESG Telechat date: unknown Summary: Ready Major issues: None Minor issues: None Nits/editorial comments: - 3.1 page 4: the precondition types don't include "sec" which is mentioned after (IMHO it is because it was added after the RFC 3312 cited the page before) - 5 page 10: succesful -> successful - 5 page 10: prequisite -> pre-requisite or prerequisite - 6 page 15: there are two "des:conn" in the last example, I believe it is a typo and the second is a "conf:conn"? - 7 page 15: TCP[RFC0793] -> TCP [RFC0793] Regards francis.dup...@fdupont.fr ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
