Subject: Re: [apps-review] New Apps Area Review Team member
From: Peter Saint-Andre <[email-masked]>
To: SM <[email-masked]>
Cc: [email-masked]
Date: Wed, 28 Sep 2011 16:25:02 -0600
List-Id: Apps Area Review List <apps-review.ietf.org>

On 9/28/11 3:58 PM, SM wrote:
> Hi Sal,
>
> Welcome to the Apps Area Review Team. I added you to the apps-review
> mailing list. There is a web page with the list of members at
> http://www.apps.ietf.org/content/applications-area-review-team A list of
> previous reviews is available at
> http://www.apps.ietf.org/content/apps-review-tracker

Welcome, Sal!

> General note: Joshua Bell was unsubscribed from the mailing list as his
> email address is no longer valid. If anyone on this list has his new
> email address, could you please send it to me or ask him to email me?

I think that Josh no longer has cycles for IETF work, but I will send 
you his email address off-list.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

Date: Wed, 28 Sep 2011 14:58:01 -0700
To: Salvatore Loreto <[email-masked]>
From: SM <[email-masked]>
Cc: [email-masked]
Subject: [apps-review] New Apps Area Review Team member

Hi Sal,

Welcome to the Apps Area Review Team.  I added you to the apps-review 
mailing list.  There is a web page with the list of members at 
http://www.apps.ietf.org/content/applications-area-review-team  A 
list of previous reviews is available at 
http://www.apps.ietf.org/content/apps-review-tracker

General note:  Joshua Bell was unsubscribed from the mailing list as 
his email address is no longer valid.  If anyone on this list has his 
new email address, could you please send it to me or ask him to email me?

Best regards,
-sm

Date: Tue, 27 Sep 2011 09:55:37 -0600
From: Joe Hildebrand <[email-masked]>
To: SM <[email-masked]>, <[email-masked]>
Subject: Re: [apps-review] Apps Area considerations

I added a section on status/error codes, and added a note to base64 about
line feeds.

The XML section needs a lot more.  I'll see if I can add some stuff that
other people will disagree with to start the discussion.

On 9/27/11 9:29 AM, "SM" <[email-masked]> wrote:

> Hello,
> 
> In June 2010, there was a discussion about the web page at
> http://trac.tools.ietf.org/group/iesg/trac/wiki/TypicalAppsAreaIssues
> There were some comments from several of you.  The document is not
> meant to be a review guide.  I'll list the sections and the feedback:
> 
> - ABNF and BNF
> 
>    There wasn't any comment.
> 
> - Base64
> 
>    There wasn't any comment.
> 
> - Byte Order
> 
>    There wasn't any comment.
> 
> -  Dates and Times
> 
>    Martin mentioned http://www.w3.org/TR/2005/NOTE-timezone-20051013/
> 
> - Internationalization
> 
>    It was mentioned not to refer to RFC 2777.  There is BCP 47 about
> language tags.
> 
> - IDNs
> 
>    This comes up every now and then.
> 
> - Passwords
> 
>    The Precis work is not mentioned.
> 
> - Media Types
> 
>   I don't recall any discussion about that.
> 
> - Security
> 
>    Are people OK with RFC 6125?
> 
> - Versioning
> 
>   This is usually an issue.
> 
> - XML
> 
>    There wasn't any comment.
> 
> I understand that there aren't any easy answers to some of the
> above.  However, if we cannot provide pointers to authors, it makes
> their work more difficult.  Is there any interest in cleaning up that web
> page?
> 
> Best regards,
> -sm
> 
> _______________________________________________
> apps-review mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/apps-review

-- 
Joe Hildebrand

Date: Tue, 27 Sep 2011 08:39:44 -0700
From: Dave CROCKER <[email-masked]>
Organization: Brandenburg InternetWorking
To: [email-masked]
Subject: Re: [apps-review] Apps Area considerations
Reply-To: [email-masked]

On 9/27/2011 8:29 AM, SM wrote:
>
> - ABNF and BNF
>
>    There wasn't any comment.

I've modified the entry for this to be a bit more careful and accurate, since 
RFC 822 refers to its form of BNF as 'augmented'...

However the focus of this entry is to highlight the need to have specs be 
careful to cite the form of BNF being used and I certainly agree with that.

However it's a bit ironic that the BNF-checking tool that is cited does not 
declare what version /it/ checks against...

d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

Date: Tue, 27 Sep 2011 08:29:13 -0700
To: [email-masked]
From: SM <[email-masked]>
Subject: [apps-review] Apps Area considerations

Hello,

In June 2010, there was a discussion about the web page at 
http://trac.tools.ietf.org/group/iesg/trac/wiki/TypicalAppsAreaIssues 
There were some comments from several of you.  The document is not 
meant to be a review guide.  I'll list the sections and the feedback:

- ABNF and BNF

   There wasn't any comment.

- Base64

   There wasn't any comment.

- Byte Order

   There wasn't any comment.

-  Dates and Times

   Martin mentioned http://www.w3.org/TR/2005/NOTE-timezone-20051013/

- Internationalization

   It was mentioned not to refer to RFC 2777.  There is BCP 47 about 
language tags.

- IDNs

   This comes up every now and then.

- Passwords

   The Precis work is not mentioned.

- Media Types

  I don't recall any discussion about that.

- Security

   Are people OK with RFC 6125?

- Versioning

  This is usually an issue.

- XML

   There wasn't any comment.

I understand that there aren't any easy answers to some of the 
above.  However, if we cannot provide pointers to authors, it makes 
their work more difficult.  Is there any interest in cleaning up that web page?

Best regards,
-sm

Sender: [email-masked]
Date: Sun, 25 Sep 2011 08:48:56 -0400
From: Barry Leiba <[email-masked]>
To: =?ISO-8859-1?Q?Martin_J=2E_D=FCrst?= <[email-masked]>
Cc: [email-masked]
Subject: Re: [apps-review] Apps review team review request template

Martin says...
> One thing I did which we currently don't say anything about is that I cc'=
ed
> the WG in charge of the document. This is mostly because if I'm in a WG t=
hat
> gets a review (e.g. security, gen-art), I'd also like to see these.

I did mention that, in my original message that you quoted, and it's
now on the wiki page:

>> Reviewers: Please send all reviews to the apps-discuss list
>> ([bold]not[/bold] to the apps-review list), and to the ".all" tools
>> alias for the specification you are reviewing (see below)! =A0In cases
>> where your review recommends significant changes to a working-group
>> document, you should also consider copying the working group's mailing
>> list.

Barry

Date: Sun, 25 Sep 2011 10:20:49 +0900
From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= <[email-masked]>
Organization: Aoyama Gakuin University
To: Barry Leiba <[email-masked]>
Cc: [email-masked]
Subject: Re: [apps-review] Apps review team review request template

Just for the record - As one of the recent offenders, and probably the 
one who triggered this proposal, I agree with these changes.

What I did when I wrote up the review was to look at an older example 
and follow that. Apparently, that was also mistaken, or was too old.

One thing I did which we currently don't say anything about is that I 
cc'ed the WG in charge of the document. This is mostly because if I'm in 
a WG that gets a review (e.g. security, gen-art), I'd also like to see 
these.

What do others think?

Regards,   Martin.

On 2011/09/24 0:18, Barry Leiba wrote:
> Hi, SM.
> Seeing how many reviewers post their reviews to apps-review prompts me
> to suggest a change to the up-front paragraph of your review request
> template.  I suggest this (example taken from a recent review
> request):
>
> --------------------------------------------------
> OLD
> Pete requested a review of draft-ietf-p2psip-base-18.  The review has
> been assigned to you and is due before September 4.
>
> NEW
> Pete requested a review of draft-ietf-p2psip-base-18.  The review has
> been assigned to you and is due before September 4.  Please post your
> review to apps-discuss (see below), and DO NOT post it to apps-review.
> --------------------------------------------------
> OLD
> The review should be sent to apps-discuss, the authors, the IESG, the
> WG Chairs and document shepherd, if applicable.
>
> NEW
> The review should be sent to apps-discuss, the IESG, the authors, the
> WG Chairs and document shepherd, if applicable.  You can use the tools
> alias [email-masked] to cover the authors,
> chairs, and shepherd.  If your review recommends significant changes
> to a working-group document, you should also consider copying the
> working group's mailing list.
>
> Suggested distribution:
>     To: [email-masked], [email-masked]
>     cc: [email-masked]
> --------------------------------------------------
>
>
> I think that makes it easier for the reviewers to get it right, and
> not all the reviewers know how to use the tools aliases, so I think
> this will help.  Want to try it?
>
> I would also update the wiki, but I can't see how to (can you tell
> me?).  If you want to, here's my suggestion for
> http://www.apps.ietf.org/content/apps-review-template
>
> --------------------------------------------------
> OLD
> This page provides a template for reviews provided by members of the
> Apps-Review Team.
> Reviewers: Please send all reviews to the apps-discuss list and make
> sure to cc the author(s) of the specification you are reviewing! You
> might also want to check out some samples, such as the reviews of
> draft-wahl-ldap-p3p, draft-ietf-btns-c-api,
> draft-ietf-calsify-2446bis, draft-merrick-jms-uri, and
> draft-dusseault-http-patch-15.
>
> NEW
> This page provides a template for reviews provided by members of the
> Apps-Review Team.
>
> Reviewers: Please send all reviews to the apps-discuss list
> ([bold]not[/bold] to the apps-review list), and to the ".all" tools
> alias for the specification you are reviewing (see below)!  In cases
> where your review recommends significant changes to a working-group
> document, you should also consider copying the working group's mailing
> list.
>
> You might also want to check out some samples, such as the reviews of
> draft-wahl-ldap-p3p, draft-ietf-btns-c-api,
> draft-ietf-calsify-2446bis, draft-merrick-jms-uri, and
> draft-dusseault-http-patch-15.
>
> Suggested distribution list for reviews:
>     To: [email-masked], [email-masked]
>     cc: [email-masked]
> --------------------------------------------------
>
> Barry
> _______________________________________________
> apps-review mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/apps-review
>

Date: Sat, 24 Sep 2011 23:17:16 +0200 (CEST)
From: Claudio Allocchio <[email-masked]>
To: Alexey Melnikov <[email-masked]>
Cc: [email-masked]
Subject: Re: [apps-review] Directorate

On Sat, 24 Sep 2011, Alexey Melnikov wrote:

> SM wrote:
>
>> Hello,
>> 
>> Most IETF areas have a directorate.  In the Applications Area, there are 
>> the LDAP and XML Directorates.  The only two review teams are Gen-ART and 
>> this team.  I welcome your advice on whether it would be better if the 
>> review team is turned into a directorate.  The advantages I can think of 
>> are:
>>
>>  - It helps in your day job.
>>
>>  - It may influence more reviewers to join the team.
>>
>>  - I can ask you to do more early reviews. :-)
>> 
>> I have not asked Apps ADs what they think about the idea.
>
> Are we going to get cool T-shirt and can we get expensive dinners covered?

...no ... somebody will just have more reason to tell that we are OLD with 
white long beards !  :-)))  and they will say that we do not understand 
social networks, too ;-)

besides jokes... well it will not help in my daily work, but it sems a 
probably correct formal definition for what we do !

... but t-shirts and dinners are always welcome!

>
> _______________________________________________
> apps-review mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/apps-review
>

------------------------------------------------------------------------------
Claudio Allocchio             G   A   R   R          [email-masked]
                         Senior Technical Officer
tel: +39 040 3758523      Italian Academic and       G=Claudio; S=Allocchio;
fax: +39 040 3758565        Research Network         P=garr; A=garr; C=it;

            PGP Key: http://www.cert.garr.it/PGP/keys.php3#ca

Date: Sat, 24 Sep 2011 08:25:39 -0700
To: Alexey Melnikov <[email-masked]>
From: SM <[email-masked]>
Cc: [email-masked]
Subject: Re: [apps-review] Directorate

Hi Alexey,
At 07:06 24-09-2011, Alexey Melnikov wrote:
>Are we going to get cool T-shirt and can we get expensive dinners covered?

You already get a cool T-shirt by attending a meeting.  As for 
expensive dinners, there is probably someone out there who would be 
more than happy to invite you if you are an AD.  An AD's undivided 
attention does not come cheap these days. :-)

Best regards,
-sm 

Date: Sat, 24 Sep 2011 16:10:59 +0100
From: Alexey Melnikov <[email-masked]>
To: Barry Leiba <[email-masked]>
Cc: [email-masked]
Subject: Re: [apps-review] Apps review team review request template

Barry Leiba wrote:

>Hi, SM.
>Seeing how many reviewers post their reviews to apps-review prompts me
>to suggest a change to the up-front paragraph of your review request
>template.  I suggest this (example taken from a recent review
>request):
>
>--------------------------------------------------
>OLD
>Pete requested a review of draft-ietf-p2psip-base-18.  The review has
>been assigned to you and is due before September 4.
>
>NEW
>Pete requested a review of draft-ietf-p2psip-base-18.  The review has
>been assigned to you and is due before September 4.  Please post your
>review to apps-discuss (see below), and DO NOT post it to apps-review.
>--------------------------------------------------
>OLD
>The review should be sent to apps-discuss, the authors, the IESG, the
>WG Chairs and document shepherd, if applicable.
>
>NEW
>The review should be sent to apps-discuss, the IESG, the authors, the
>WG Chairs and document shepherd, if applicable.  You can use the tools
>alias [email-masked] to cover the authors,
>chairs, and shepherd.  If your review recommends significant changes
>to a working-group document, you should also consider copying the
>working group's mailing list.
>
>Suggested distribution:
>   To: [email-masked], [email-masked]
>   cc: [email-masked]
>--------------------------------------------------
>
>
>I think that makes it easier for the reviewers to get it right, and
>not all the reviewers know how to use the tools aliases, so I think
>this will help.  Want to try it?
>  
>
This make sense.

>I would also update the wiki, but I can't see how to (can you tell
>me?).  If you want to, here's my suggestion for
>http://www.apps.ietf.org/content/apps-review-template
>
>--------------------------------------------------
>OLD
>This page provides a template for reviews provided by members of the
>Apps-Review Team.
>Reviewers: Please send all reviews to the apps-discuss list and make
>sure to cc the author(s) of the specification you are reviewing! You
>might also want to check out some samples, such as the reviews of
>draft-wahl-ldap-p3p, draft-ietf-btns-c-api,
>draft-ietf-calsify-2446bis, draft-merrick-jms-uri, and
>draft-dusseault-http-patch-15.
>
>NEW
>This page provides a template for reviews provided by members of the
>Apps-Review Team.
>
>Reviewers: Please send all reviews to the apps-discuss list
>([bold]not[/bold] to the apps-review list), and to the ".all" tools
>alias for the specification you are reviewing (see below)!  In cases
>where your review recommends significant changes to a working-group
>document, you should also consider copying the working group's mailing
>list.
>
>You might also want to check out some samples, such as the reviews of
>draft-wahl-ldap-p3p, draft-ietf-btns-c-api,
>draft-ietf-calsify-2446bis, draft-merrick-jms-uri, and
>draft-dusseault-http-patch-15.
>
>Suggested distribution list for reviews:
>   To: [email-masked], [email-masked]
>   cc: [email-masked]
>--------------------------------------------------
>
>Barry
>

Date: Sat, 24 Sep 2011 16:18:22 +0200
From: Eliot Lear <[email-masked]>
To: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= <[email-masked]>
Cc: [email-masked]
Subject: Re: [apps-review] Directorate

Either review team or directorate is fine with me.

Date: Sat, 24 Sep 2011 15:06:38 +0100
From: Alexey Melnikov <[email-masked]>
To: SM <[email-masked]>
Cc: [email-masked]
Subject: Re: [apps-review] Directorate

SM wrote:

> Hello,
>
> Most IETF areas have a directorate.  In the Applications Area, there 
> are the LDAP and XML Directorates.  The only two review teams are 
> Gen-ART and this team.  I welcome your advice on whether it would be 
> better if the review team is turned into a directorate.  The 
> advantages I can think of are:
>
>  - It helps in your day job.
>
>  - It may influence more reviewers to join the team.
>
>  - I can ask you to do more early reviews. :-)
>
> I have not asked Apps ADs what they think about the idea.

Are we going to get cool T-shirt and can we get expensive dinners covered?

Date: Sat, 24 Sep 2011 16:15:34 +0900
From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= <[email-masked]>
Organization: Aoyama Gakuin University
To: SM <[email-masked]>
Cc: [email-masked]
Subject: Re: [apps-review] Directorate

I don't think this will help me in my day job, but looking at 
http://www.ietf.org/iesg/directorate/, it seems to fit what we are doing 
well, and the Gen-ART Review Team is already listed, so it seems to make 
a lot of sense even just for streamlining.

Regards,    Martin.

On 2011/09/24 7:32, SM wrote:
> Hello,
>
> Most IETF areas have a directorate. In the Applications Area, there are
> the LDAP and XML Directorates. The only two review teams are Gen-ART and
> this team. I welcome your advice on whether it would be better if the
> review team is turned into a directorate. The advantages I can think of
> are:
>
> - It helps in your day job.
>
> - It may influence more reviewers to join the team.
>
> - I can ask you to do more early reviews. :-)
>
> I have not asked Apps ADs what they think about the idea.
>
> Best regards,
> -sm
>
> _______________________________________________
> apps-review mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/apps-review
>

Sender: [email-masked]
Date: Fri, 23 Sep 2011 23:09:39 -0400
From: Barry Leiba <[email-masked]>
To: SM <[email-masked]>
Cc: [email-masked]
Subject: Re: [apps-review] Directorate

> Most IETF areas have a directorate. =A0In the Applications Area, there ar=
e the
> LDAP and XML Directorates. =A0The only two review teams are Gen-ART and t=
his
> team. =A0I welcome your advice on whether it would be better if the revie=
w
> team is turned into a directorate.

I see no reason not to formally change it to a directorate.  Sounds good to=
 me.

Barry

Date: Fri, 23 Sep 2011 15:32:41 -0700
To: [email-masked]
From: SM <[email-masked]>
Subject: [apps-review] Directorate

Hello,

Most IETF areas have a directorate.  In the Applications Area, there 
are the LDAP and XML Directorates.  The only two review teams are 
Gen-ART and this team.  I welcome your advice on whether it would be 
better if the review team is turned into a directorate.  The 
advantages I can think of are:

  - It helps in your day job.

  - It may influence more reviewers to join the team.

  - I can ask you to do more early reviews. :-)

I have not asked Apps ADs what they think about the idea.

Best regards,
-sm

Date: Fri, 23 Sep 2011 14:51:31 -0700
To: Barry Leiba <[email-masked]>
From: SM <[email-masked]>
Cc: [email-masked]
Subject: Re: [apps-review] Apps review team review request template

Hi Barry,
At 14:11 23-09-2011, Barry Leiba wrote:
>I think it's not.  I would mention pervasive or significant editorial
>points (for example, if something is consistently wrong through the
>document, or if the grammar is particularly bad, such that another
>editor with better English skills should be added), but I wouldn't
>bother picking small points in an early review.

Thanks for the advice.  I am going to follow it.

>Ah.  So this isn't plugged into the regular tools wiki, then?  Can
>that be changed?  Or should we leave it?  What do the ADs think?

No, www.apps.ietf.org is not part of IETF infrastructure or run by 
the Tools teams.  I had a short discussion about that with the Apps 
ADs last year.  I preferred to leave it.

Best regards,
-sm 

Sender: [email-masked]
Date: Fri, 23 Sep 2011 17:11:40 -0400
From: Barry Leiba <[email-masked]>
To: SM <[email-masked]>
Cc: [email-masked]
Subject: Re: [apps-review] Apps review team review request template

>> Seeing how many reviewers post their reviews to apps-review prompts me
>> to suggest a change to the up-front paragraph of your review request
>> template. =A0I suggest this (example taken from a recent review
>> request):
>
> As a general comment, we send the review to apps-discuss as it has a wide=
r
> readership.

Yes, I know.  And when people post their reviews to apps-review
instead, you wind up having to forward them to apps-discuss.  Better
if we can fend that off.

> General comment, some of the reviews are early reviews, i.e. they are
> performed before a Last Call has been initiated. =A0It is easier to ask f=
or a
> change and less work for the author/working group. =A0I don't ask for a C=
c to
> the IESG in such cases. =A0If the Apps ADs or anyone thinks that it is
> appropriate to also copy the IESG in such cases, please let me know.

No, I think it's fine as it is.  Obviously, you'd adjust your text
accordingly, recommending a cc to the IESG or not, as appropriate.

> I would like to ask you whether it is worth picking editorial nits in an
> early review.

I think it's not.  I would mention pervasive or significant editorial
points (for example, if something is consistently wrong through the
document, or if the grammar is particularly bad, such that another
editor with better English skills should be added), but I wouldn't
bother picking small points in an early review.

>> I would also update the wiki, but I can't see how to (can you tell
>> me?). =A0If you want to, here's my suggestion for
>
> Please ask Ned for a login for http://www.apps.ietf.org/user/ =A0If anyon=
e
> needs a login, feel free to email me.

Ah.  So this isn't plugged into the regular tools wiki, then?  Can
that be changed?  Or should we leave it?  What do the ADs think?

Barry

Date: Fri, 23 Sep 2011 13:56:37 -0700
To: Barry Leiba <[email-masked]>
From: SM <[email-masked]>
Cc: [email-masked]
Subject: Re: [apps-review] Apps review team review request template

Hi Barry,
At 08:18 23-09-2011, Barry Leiba wrote:
>Seeing how many reviewers post their reviews to apps-review prompts me
>to suggest a change to the up-front paragraph of your review request
>template.  I suggest this (example taken from a recent review
>request):

Thanks for the thoughtful comments.  I'll use your new text.

As a general comment, we send the review to apps-discuss as it has a 
wider readership.

>--------------------------------------------------
>OLD
>The review should be sent to apps-discuss, the authors, the IESG, the
>WG Chairs and document shepherd, if applicable.
>
>NEW
>The review should be sent to apps-discuss, the IESG, the authors, the
>WG Chairs and document shepherd, if applicable.  You can use the tools
>alias [email-masked] to cover the authors,
>chairs, and shepherd.  If your review recommends significant changes
>to a working-group document, you should also consider copying the
>working group's mailing list.

Ok.

General comment, some of the reviews are early reviews, i.e. they are 
performed before a Last Call has been initiated.  It is easier to ask 
for a change and less work for the author/working group.  I don't ask 
for a Cc to the IESG in such cases.  If the Apps ADs or anyone thinks 
that it is appropriate to also copy the IESG in such cases, please let me know.

I would like to ask you whether it is worth picking editorial nits in 
an early review.

>Suggested distribution:
>    To: [email-masked], [email-masked]
>    cc: [email-masked]
>--------------------------------------------------
>
>
>I think that makes it easier for the reviewers to get it right, and
>not all the reviewers know how to use the tools aliases, so I think
>this will help.  Want to try it?

I will try that.

>I would also update the wiki, but I can't see how to (can you tell
>me?).  If you want to, here's my suggestion for

Please ask Ned for a login for http://www.apps.ietf.org/user/  If 
anyone needs a login, feel free to email me.

>http://www.apps.ietf.org/content/apps-review-template
>
>--------------------------------------------------
>OLD
>This page provides a template for reviews provided by members of the
>Apps-Review Team.
>Reviewers: Please send all reviews to the apps-discuss list and make
>sure to cc the author(s) of the specification you are reviewing! You
>might also want to check out some samples, such as the reviews of
>draft-wahl-ldap-p3p, draft-ietf-btns-c-api,
>draft-ietf-calsify-2446bis, draft-merrick-jms-uri, and
>draft-dusseault-http-patch-15.
>
>NEW
>This page provides a template for reviews provided by members of the
>Apps-Review Team.
>
>Reviewers: Please send all reviews to the apps-discuss list
>([bold]not[/bold] to the apps-review list), and to the ".all" tools
>alias for the specification you are reviewing (see below)!  In cases
>where your review recommends significant changes to a working-group
>document, you should also consider copying the working group's mailing
>list.
>
>You might also want to check out some samples, such as the reviews of
>draft-wahl-ldap-p3p, draft-ietf-btns-c-api,
>draft-ietf-calsify-2446bis, draft-merrick-jms-uri, and
>draft-dusseault-http-patch-15.
>
>Suggested distribution list for reviews:
>    To: [email-masked], 
> [email-masked]
>    cc: [email-masked]
>--------------------------------------------------

That looks good.  I posted your change.  Feel free to edit it.

Should the examples be updated?

BTW, if you have notice any drafts from other areas that might 
benefit from an early review, please let me know.

Best regards,
-sm 

Sender: [email-masked]
Date: Fri, 23 Sep 2011 11:18:58 -0400
From: Barry Leiba <[email-masked]>
To: SM <[email-masked]>
Cc: [email-masked]
Subject: [apps-review] Apps review team review request template

Hi, SM.
Seeing how many reviewers post their reviews to apps-review prompts me
to suggest a change to the up-front paragraph of your review request
template.  I suggest this (example taken from a recent review
request):

--------------------------------------------------
OLD
Pete requested a review of draft-ietf-p2psip-base-18.  The review has
been assigned to you and is due before September 4.

NEW
Pete requested a review of draft-ietf-p2psip-base-18.  The review has
been assigned to you and is due before September 4.  Please post your
review to apps-discuss (see below), and DO NOT post it to apps-review.
--------------------------------------------------
OLD
The review should be sent to apps-discuss, the authors, the IESG, the
WG Chairs and document shepherd, if applicable.

NEW
The review should be sent to apps-discuss, the IESG, the authors, the
WG Chairs and document shepherd, if applicable.  You can use the tools
alias [email-masked] to cover the authors,
chairs, and shepherd.  If your review recommends significant changes
to a working-group document, you should also consider copying the
working group's mailing list.

Suggested distribution:
   To: [email-masked], [email-masked]
   cc: [email-masked]
--------------------------------------------------

I think that makes it easier for the reviewers to get it right, and
not all the reviewers know how to use the tools aliases, so I think
this will help.  Want to try it?

I would also update the wiki, but I can't see how to (can you tell
me?).  If you want to, here's my suggestion for
http://www.apps.ietf.org/content/apps-review-template

--------------------------------------------------
OLD
This page provides a template for reviews provided by members of the
Apps-Review Team.
Reviewers: Please send all reviews to the apps-discuss list and make
sure to cc the author(s) of the specification you are reviewing! You
might also want to check out some samples, such as the reviews of
draft-wahl-ldap-p3p, draft-ietf-btns-c-api,
draft-ietf-calsify-2446bis, draft-merrick-jms-uri, and
draft-dusseault-http-patch-15.

NEW
This page provides a template for reviews provided by members of the
Apps-Review Team.

Reviewers: Please send all reviews to the apps-discuss list
([bold]not[/bold] to the apps-review list), and to the ".all" tools
alias for the specification you are reviewing (see below)!  In cases
where your review recommends significant changes to a working-group
document, you should also consider copying the working group's mailing
list.

You might also want to check out some samples, such as the reviews of
draft-wahl-ldap-p3p, draft-ietf-btns-c-api,
draft-ietf-calsify-2446bis, draft-merrick-jms-uri, and
draft-dusseault-http-patch-15.

Suggested distribution list for reviews:
   To: [email-masked], [email-masked]
   cc: [email-masked]
--------------------------------------------------

Barry

Date: Thu, 22 Sep 2011 20:48:14 +0900
From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= <[email-masked]>
Organization: Aoyama Gakuin University
To: Henning Schulzrinne <[email-masked]>, Hannes Tschofenig <[email-masked]>
Cc: Marc Linsner <[email-masked]>, "[email-masked]" <[email-masked]>, [email-masked], Robert Sparks <[email-masked]>
Subject: [apps-review] review of draft-ietf-ecrit-lost-sync-12

I have been selected as the Applications Area Review Team reviewer for 
this draft (for background on apps-review, please see 
http://www.apps.ietf.org/content/applications-area-review-team).

Document: draft-ietf-ecrit-lost-sync-12
Reviewer: Martin Dürst
Review Date: September 22, 2011

Review Summary:

This draft should be clarified in various places before being published.
There is also a deeper design issue that I will mention upfront and that 
hopefully will be taken to heart for future work.

Document Summary:

The document defines a 'protocol' (actually a number of XML messages, 
under a common Media type, carried over http(s)) for synchronizing 
Location-to-Service Translation (LoST) service boundaries and mapping 
elements.

Design Issue:

It seems still in fashion to define a 'protocol' independent of 
underlying transport. This is preferable if there is a truely expected 
need for multiple transports, and if there is a large abstraction gap 
between the newly defined 'protocol' and the potential underlying 
transport mechanism. However, in the case at hand, only one transport 
(HTTP, including its secured equivalent HTTPS) is used, and the 
abstraction gap is extremely low.

Once one has understood REST, it's very easy to see a set of mappings as 
a resource, a <getMappingRequest> as a simple HTTP GET and a 
<pushMappingRequest> as a PUT. A <getMappingRequest> with 
<mapping-fingerprint> element would require some thought, although there 
are several possible solutions.

Major Issues (necessary clarifications):

Independence of LoST: The Introduction says:
    In any case, this document can also be
    used without the LoST protocol even though the format of the
    <mapping> element is re-used from the LoST specification.
What does "can be used without the LoST protocol" mean? If it said 
something like "this specification is independent of the LoST protocol 
specification except in that it reuses the <mapping> element (and some 
error elements) from that specification", that would be easier to 
understand.

Namespaces: It is overkill to define new namespaces for each spec. It's 
a well-known secret in the XML community that it's easily possible to 
add a number of new elements to an existing namespace. This would be 
very appropriate in this case, because the number of reused elements and 
attributes is quite large, and the number of new elements is low. This 
would simplify most of the examples.

4.2 Behavior of the LoST Sync Destination: This needs various 
clarifications.

The first paragraph uses 'replace', the next one after the conditions 
uses 'update'. Is this the same? Then use the same word. Also, it says:
    If the received mapping M' does not update any existing mapping M
    then it MUST be added to the local cache as an independent mapping.
If I apply this to a mapping with conditions 1. and 2. being true, but 
condition 3. being false, then this means that older mappings of the 
same source and sourceID MUST be added to the local cache. Surely this 
must be wrong.

Also, it says that an emply <mapping> element means that a 
"corresponding" mapping has to be determined based on source, sourceID, 
and lastUpdated. The "lastUpdated" here is ambiguous and could lead to 
differing implementations. Does lastUpdated have to match with equality? 
Does it have to be (the same or?) newer than the one being cached?

Also, all the examples (Figs. 10/12) also contain an 'expires' 
attribute. Is that necessary? Does it have to be the same as the 
lastUpdated attribute? Please specify.

Further, we have: "The <notDeleted> element MAY carry a <message> 
element": What kind of message element? If this is from RFC 5222, then 
please say so. In Fig. 12, there is a 'message' attribute, is that what 
is meant? If yes, then please fix the prose (element-> attribute). If 
no, then point out the difference.

Fig. 12: This uses an attribute value for human-readable text. This is 
considered bad practice, because it forecloses the use of further markup 
in case this is considered necessary (can often become the case for 
internationalization reasons).

in Transport, it says:
    The HTTP request MUST use the
    Cache-Control response directive "no-cache" to (*) HTTP-level caching
At (*), a verb such as 'suppress' or 'avoid' or some such seems to be 
missing. Please clarify.

In Operational Considerations, the use of XML Digital Signatures is 
mentioned. With just the text that is there, it seems impossible to 
guess what actually should be done. For example, how is authorization 
verified? Also, why only sign the first time? Wouldn't it be easier/more 
straightforward to just sign every time?
This looks like either an afterthought (in which case the MUST isn't 
appropriate, because it doesn't have anything to do with the protocol 
per se) or some missing context (e.g. from LoST itself) in which case 
there should be some reference or so to clarify the context.

Security Considerations: In particular the last two sentences read like 
security considerations not for synchronization, but for the underlying 
PSAP data and LoST itself. Probably similar considerations have already 
been given in RFC 5222 or elsewhere, in which case they should be 
included by reference.

9.1: "8-bit characters": This term is highly inappropriate, because it's 
actually 8-bit bytes, not characters. Please just point to RFC 3023.

9.1, security considerations: Replace the current text with a pointer to 
the security considerations in the spec (text similar to the "Published 
Specification" item)

p. 25: The namespace document has the namespace as
urn:ietf:params:xml:ns:lost1:sync, while in the examples it is
urn:ietf:params:xml:ns:lostsync1. Please fix and check carefully.

Minor Issues (mainly editorial):

Abstract and Introduction: add a comma at end of clause
    The main data structure, the <mapping> element, used for
    encapsulating information about service boundaries*,* is defined...

p.4: "we call them Austria and Finland": "we call them" makes sense with 
fictive country names, but in this case "for example Austria and 
Finland" makes more sense.

p. 8: "Node B issuing the first request and plays"
    -> "Node B is issuing the first request and plays"

p. 12: There should be a short explanation of the <mapping-fingerprint> 
element in the prose.

4.3: The first two example given with bullet points add a linebreak 
after the first attribute, it would be easier if they also added a 
linebreak after the second one.

6. Relax: Please add some introductory text.

7. Operational Considerations:
    When B obtained this new mapping it would find out that it has to
    distribute it to its peer C. C would also want to distribute the
    mapping to B (and vice versa).
Either remove the 'vice versa' or the sentence before it.

"If the originally mapping" ->
"If the original mapping"

Security Considerations: Split the long paragraph into shorter pieces 
for easier readability.

9.1, Additional Information: Please add "None"

10. In earlier times, the shepherd was called the PROTO shepherd. But 
these days, PROTO isn't used anymore as far as I know. Please remove.

Regards,    Martin.

From: "Murray S. Kucherawy" <[email-masked]>
To: Randall Gellens <[email-masked]>, "[email-masked]" <[email-masked]>, Barry Leiba <[email-masked]>
Date: Wed, 21 Sep 2011 16:24:16 -0700
Accept-Language: en-US
acceptlanguage: en-US
Subject: Re: [apps-review] draft-ietf-appsawg-rfc3462bis

> -----Original Message-----
> From: Randall Gellens [mailto:[email-masked]]
> Sent: Wednesday, September 21, 2011 3:58 PM
> To: [email-masked]; Murray S. Kucherawy; Barry Leiba
> Subject: draft-ietf-appsawg-rfc3462bis
>=20
> This document looks good.
>=20
> One minor request:
>=20
> In Section 4, under "Encoding considerations", I'd recommend either
> deleting "are broken" or adding "or extended".  (In my view, this
> makes it easier for EAI.)
>=20
> OLD:
>        Encoding considerations:  7-bit is sufficient for normal mail
>        headers, however, if the headers are broken and require encoding
>=20
> NEW:
>        Encoding considerations:  7-bit is sufficient for normal mail
>        headers, however, if the headers require encoding
>=20
> OR:
>        Encoding considerations:  7-bit is sufficient for normal mail
>        headers, however, if the headers are broken or extended
>        and require encoding

Went with the latter in my working copy. Thanks!

-MSK

Date: Wed, 21 Sep 2011 15:57:47 -0700
To: [email-masked], Murray Kucherawy <[email-masked]>, Barry Leiba <[email-masked]>
From: Randall Gellens <[email-masked]>
Subject: [apps-review] draft-ietf-appsawg-rfc3462bis

This document looks good.

One minor request:

In Section 4, under "Encoding considerations", I'd recommend either 
deleting "are broken" or adding "or extended".  (In my view, this 
makes it easier for EAI.)

OLD:
       Encoding considerations:  7-bit is sufficient for normal mail
       headers, however, if the headers are broken and require encoding

NEW:
       Encoding considerations:  7-bit is sufficient for normal mail
       headers, however, if the headers require encoding

OR:
       Encoding considerations:  7-bit is sufficient for normal mail
       headers, however, if the headers are broken or extended
       and require encoding

-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
Vous etes ici

Date: Mon, 19 Sep 2011 02:24:31 -0700
To: "Martin J. Durst" <[email-masked]>
From: SM <[email-masked]>
Cc: [email-masked]
Subject: Re: [apps-review] Request for review: draft-ietf-ecrit-lost-sync-12

Hi Martin,
At 02:10 19-09-2011, Martin J. Durst wrote:
>I should be able to review this, but would prefer to get some more 
>time, e.g. until Sept. 23.

That's fine.

Best regards,
-sm 

Date: Mon, 19 Sep 2011 18:10:35 +0900
From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= <[email-masked]>
Organization: Aoyama Gakuin University
To: SM <[email-masked]>
Cc: [email-masked]
Subject: Re: [apps-review] Request for review: draft-ietf-ecrit-lost-sync-12

Hello SM,

On 2011/09/18 2:29, SM wrote:
> Hi Martin,
>
> Could you please take over the review of draft-ietf-ecrit-lost-sync-12
> before September 21?

I should be able to review this, but would prefer to get some more time, 
e.g. until Sept. 23.

Regards,   Martin.

> Thanks,
> -sm
>
>

Date: Sat, 17 Sep 2011 10:29:54 -0700
To: =?iso-8859-1?Q?=22Martin_J=2E_D=FCrst=22?= <[email-masked]>
From: SM <[email-masked]>
Cc: [email-masked]
Subject: Re: [apps-review] Request for review: draft-ietf-ecrit-lost-sync-12

Hi Martin,

Could you please take over the review of 
draft-ietf-ecrit-lost-sync-12 before September 21?

Thanks,
-sm

From: "Murray S. Kucherawy" <[email-masked]>
To: "[email-masked]" <[email-masked]>
Date: Wed, 14 Sep 2011 11:20:56 -0700
Accept-Language: en-US
acceptlanguage: en-US
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [apps-review] apps-team review of draft-ietf-mif-dns-server-selection

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Wednesday, September 14, 2011 6:56 AM
> To: Murray S. Kucherawy
> Cc: [email-masked]; [email-masked]; [email-masked]
> Subject: RE: apps-team review of draft-ietf-mif-dns-server-selection
>=20
> Thank you very much for your extensive review, I have replied and comment=
ed
> inline. I cc'd mif, apps-ads, and apps-review - hope it is ok.

Fine with me, though I can't reply to mif since I'm not on it so I've dropp=
ed it from this reply.  Feel free to forward this as well.

> Minor Issues:
> . The IANA Considerations section seems to be a little understated. =A0I =
would
> suggest copying the one from RFC3646 and modifying it accordingly.
>=20
> Teemu>Roger that, I updated my -05 candidate IANA considerations section =
to
> look following (as of now):
> --
>    This memo requests IANA to assign two new option codes.  First option
>    code is requested to be assigned for DHCPv4 DNS Server Selection
>    option (TBD) from the DHCP option code space defined in section "New
>    DHCP option codes" of RFC 2939.  Second option code is requested to
>    be assigned to the DHCPv6 DNS Server Selection option (TBD) from the
>    DHCPv6 option code space defined in section "IANA Considerations" of
>    RFC 3315.
> --

That's probably good enough.  It will be replaced again by the RFC Editor w=
hen IANA does the assignment, but it's more clear here what you are request=
ing.

> . The use of "domain" in the first paragraph of Section 1 is ambiguous.=
=A0 The
> word "domain" is unfortunately overloaded to mean management domain, DNS
> domain, and probably some others, plus the usual dictionary definition.=
=A0 I
> recommend simply saying "a solution for IPv6."=A0 Don't be surprised if a=
 DNS
> Directorate reviewer complains about this as well.
>=20
> Teemu>It now says:".multi-interfaced nodes and provides a solution", as t=
he
> solution is proposed for both IPv4 and IPv6.

OK.

> . The document in general makes use of the term "DNS suffix".=A0 It could=
 be
> that I've simply never encountered the term before, but it took me a whil=
e
> of reading to realize this actually meant "domain name".=A0 I would sugge=
st
> clarifying this up front someplace, or changing it to "domain name"
> throughout.
>=20
> Teemu>It was changed to "domain" throughout. However, for section 4.1 (wh=
ere
> this is introduced) I added further clarification that "domain" is referr=
ing
> to "DNS domain name suffixes":
> --
> ...matching to specific DNS domain name suffixes or reverse (PTR record) =
lookup
>           requests matching to specific network addresses (later referred=
 as
> "domain" and "network").
> --

I still think the use of "suffix" is odd, though it's hard to argue that it=
's technically incorrect.  For foobar.nokia.com, I would think "nokia.com" =
is the domain name, not a suffix attached to the name "foobar".  I'd be mor=
e comfortable with calling "foobar" a prefix, but even that doesn't seem ri=
ght to me.

If you really like the term "suffix", I suggest putting a paragraph somewhe=
re early on saying "When we use the term 'DNS suffix', we actually mean a d=
omain name that is the root of future queries in common" or something like =
that.

> . The last paragraph of Section 2.4 is confusing.=A0 It says "After the
> interface change[,] a host could have both positive and negative DNS cach=
e
> entries no longer valid on the new network interface."=A0 Should that
> "both.and" be "either.or"?=A0 I'm not clear on how a single node can have=
 both
> positive and negative DNS cache entries no longer valid on the new
> interface, unless you mean some of its cache will be positive and wrong a=
nd
> some of its cache will be negative and wrong (about different names) afte=
r
> the move.=A0 This should be clarified.
>=20
> Teemu> Section 2.2..  It tries to say any cached entry may or may not be
> valid after interface change - as you guessed. How about:
> --
> A thing worth noting is that network specific IP addresses can cause
> problems also for a single-homed node, if the node retains DNS cache duri=
ng
> movement from one network to another. After the network change, a node ma=
y
> have both wrong positive and wrong negative entries in its DNS cache.> --

I suggest:

It is worth noting is that network specific IP addresses can cause
problems also for a single-homed node, if the node retains DNS cache during
movement from one network to another. After the network change, a node may
have entries in its DNS cache that are no longer correct or appropriate for=
 its
new network position.

> . I found it strange to read RFC2119 normative language Section 4.1 which
> describes an internal-use algorithm for collecting and organizing data
> learned from DHCP and DHCPv6 to build up a set of rules for deciding whic=
h
> nameserver(s) to use for which queries.=A0 The same sort of thing appeare=
d
> later in Sections 4.5 and 4.6.=A0 My understanding is that, since DHCP an=
d
> DHCPv6 are the wire protocols used and this section describes an
> internal-use mechanism, these bits of the text shouldn't include any RFC2=
119
> language; there is nothing here that affects interoperability between two
> nodes implementing this protocol.=A0 If a node implementing this gets it
> wrong, it only hurts itself; the wire protocols don't break.=A0 If this
> section were to be separated into its own document, it would be
> Informational, not Standards Track.=A0 This isn't a showstopper for me, b=
ut I
> did find it unusual.
>=20
> Teemu>The normative text for this algorithm is there mostly due concerns
> that otherwise this option could open a new attack vector. By describing =
how
> a node MUST handle the information it receives, the risk of attacks shoul=
d
> be decreased. The normative text is there also so that if a node claims
> compliancy to RFC, network operator who provides such options (to build a
> system) could expect a node to behave as is described.

OK.  In that case, I suggest that this be stated either before the normativ=
e stuff begins, or along with it, to show how important it is that this be =
the way things are done.

Another approach would be to spell out the security implications of not pre=
cisely following the algorithm later on in Section 10.

> . There are a few places in the document, the Introduction and Section 4.=
1
> for example, that talk about PTR lookup requests matching specific IPv6
> prefixes.=A0 However, the abstract mentions IPv4 support, and the mechani=
sm is
> also described for IPv4.=A0 I suggest making a quick pass through the doc=
ument
> to be sure it doesn't appear as if IPv6 is the focus and IPv4 was added i=
n
> as an after-thought.
>=20
> Teemu>Well IPv4 was after-thought as I would have settled for IPv6-only b=
ut
> WG wanted IPv4 option as well:-)

I'm afraid I agree with the working group then.  :-)

> The -04 version should have cleared several
> of these "IPv6 focus" issues (by talking about network addresses instead =
of
> prefixes), but I guess checking again would not hurt. On the other hand,
> IPv6 really is the focus here, as multi-interface behavior with IPv4 anyw=
ay
> is terrible mess due widespread usage of RFC1918 addressed networks (and
> that's why I'm secretly hoping DHC WG would say they don't want to use DH=
CP
> option code for this option and hence this technology must be IPv6-
> only:-D.

This is also text you might want to add in there, perhaps in a later sectio=
n or an appendix, explaining why doing this in IPv4 space is more challengi=
ng.  Referring to another document that already discusses this is fine as w=
ell.

> . The normative language in Section 4.1 around DNSSEC seems to be the kin=
d
> of thing that should be left for local policy.=A0 I can envision environm=
ents
> where the client isn't doing anything sensitive enough to demand DNSSEC, =
so
> the first reply it gets from any nameserver it queried is probably fine.
> The same sort of thing reappears in Section 4.4.
>=20
> Teemu>This document should already allow such local policy. Section 4.4.
> describes possibility of "unless the node is specifically configured to d=
o
> so.". The DNSSEC requirement has been very hard on MIF WG mailing list
> discussions in order to fight against creation of new attack vectors, hen=
ce
> easing that requirement requires restarting of those discussions. See als=
o
> section 4.4 for cases where DNSSEC is not required - like the option 1:"T=
he
> server selection option is delivered across a secure, trusted channel."

I think the thing that's nagging me the most about 4.1 is this: "Therefore,=
 a DNSSEC-aware resolver MUST NOT proceed with a reply that cannot be valid=
ated using DNSSEC if DNS queries sent to other servers are still pending." =
 If my node is DNSSEC-aware and connected simultaneously to the public inte=
rnet and a corporate VPN, but neither the public nameserver nor the one on =
the corporate VPN use DNSSEC, then by this rule my node can't use any reply=
 at all.  It seems to me that ought to be a SHOULD NOT, because this is a c=
ase where my resolver can just use whatever replies it gets.

It could also be that you're saying you SHOULD NOT use any replies until (a=
) you get a DNSSEC one back or (b) you get all of them back and none of the=
m are DNSSEC-protected in which case you can use any of them at your discre=
tion.  If that's the case, then you should say so.

> . In Section 4.2, the paragraph starting "If the OPTION_DNS_SERVER_SELECT
> contains." was a little confusing to read.=A0 It says in general that whe=
n
> learning about DNS servers available, the node can update what it knows b=
ut
> can't forget what it's learned, however it can ignore things it chooses t=
o
> ignore.=A0 I found this difficult to follow.=A0 Some expansion of this
> paragraph, perhaps with examples, might help.
>=20
> Teemu>I wonder if it would be actually wiser just to keep one instance of
> the option contents in memory (from most trusted network interface?), and
> ensure all legitimate DHCP servers have the same content for the same DNS
> server option?

You might just keep everything and rank them in decreasing order of trust, =
evaluated through some appropriate means (known friendly networks first, se=
cured networks second, public networks third), and then search top-to-botto=
m when you're preparing to send a query.  That's just off the top of my hea=
d though; you guys are the experts here.  :-)

> . Section 4.4 says a node MUST NOT use the feature being described here
> unless specifically configured to do so.=A0 That seems odd.=A0 Is the int=
ent to
> have implementations force this feature off-by-default?
>=20
> Teemu>Pretty much so, due security concerns. Please note that other SDOs =
or
> organizations that create profiles may say that in their environments the
> feature shall be on-by-default.

Fair enough.  It's a minor point, but I would probably be more comfortable =
with:

Use of OPTION_DNS_SERVER_SELECT is ideal in the following environments, but=
 SHOULD NOT be enabled by default otherwise:

<and then put your list here>

> . I didn't understand this sentence in Section 4.5: "When both options ar=
e
> received from the same network interface ., the resolver MUST make the
> decision which one to prefer based on preferences."
>=20
> Teemu>modified to:"...decision which one to prefer based on DNS preferenc=
e
> field value.". Better?

Yes.

> . Section 7 says "To ensure nodes' routing . works correctly, network
> administrators should also deploy related technologies for that purpose."
> Are there any that can be suggested or referenced here?
>=20
> Teemu>I actually removed that sentence on -04 as it is probably better to
> tie different solution documents together in some other document (like at
> draft-ietf-v6ops-ipv6-multihoming-without-ipv6nat ). The reference could
> have been to RFC4191 and MIF DHCPv6 route option (at least).

Your call; removing it is fine, pointing the reader to a useful technology =
to fill that gap is fine too.

> . Appendix A is called "Best Current Practice", but the first section sta=
rts
> out "A possible current practice."=A0 Where's the best one, and why is it
> best?
>=20
> Teemu>well.. changed title of Appendix A to "Possible alternative practic=
es
> for DNS server selection". Better?

Yes.

> Nits:
> . In Section 5, the explanation bullets under Figure 7 include two DHCPv6
> replies.=A0 The second one covered "example.com" and a specific IPv6 suff=
ix,
> but it's not clear that there was no overlap with the first one (i.e., th=
e
> first one could've said the same thing).=A0 It should be made clear that =
they
> had disjoint replies.
>=20
> Teemu>Ok.. changed to:
> ---
>    2.  The node obtains domain 'domain1.example.com' and IPv6 network
>        '0.8.b.d.0.1.0.0.2.ip6.arpa' for the new interface 1 from DHCPv6
>        server
> ....
>    5.  The node obtains domain 'domain2.example.com' and IPv6 network
>        information, say '1.8.b.d.0.1.0.0.2.ip6.arpa' for the new
>        interface 2 from DHCPv6 server
> ---
> and  later in fig 8:
> --
>    1.  An application makes a request for resolving an FQDN, e.g.
>        'private.domain2.example.com'
> --

Perfect.

> . Appendix A.1 uses the term "hotspot" which is colloquial and might even=
 be
> trademarked.=A0 I suggest "wireless network".
>=20
> Teemu>That part was removed at the same time the text talking about leaki=
ng
> names was removed..

Why was that removed?  I thought it was a good point.

Good work, thanks for your response!

-MSK

From: <[email-masked]>
To: <[email-masked]>
Date: Wed, 14 Sep 2011 13:55:41 +0000
Accept-Language: en-US
Cc: [email-masked], [email-masked], [email-masked]
Subject: Re: [apps-review] apps-team review of draft-ietf-mif-dns-server-selection

------=_NextPart_000_0158_01CC72FF.21E75F20
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Thank you very much for your extensive review, I have replied and =
commented
inline. I cc=92d mif, apps-ads, and apps-review =96 hope it is ok.

Completing review of -03 revision was just fine approach, as the -04 was
created only to share updates done based on feedback for -03 that was
received by yesterday evening my time.=20

I will wait a while for additional input before uploading -05.

Best regards,

Teemu

-------
From: ext Murray S. Kucherawy [mailto:[email-masked]]=20
Sent: 14. syyskuuta 2011 10:01
To: [email-masked];
[email-masked]
Cc: [email-masked]; [email-masked]
Subject: apps-team review of draft-ietf-mif-dns-server-selection

I have been selected as the Applications Area Review Team reviewer for =
this
draft (for background on apps-review, please see
http://www.apps.ietf.org/content/applications-area-review-team).

Please resolve these comments along with any other Last Call comments =
you
may receive. Please wait for direction from your document shepherd or AD
before posting a new version of the draft.

Document: draft-ietf-mif-dns-server-selection-03
Title: Improved DNS Server Selection for Multi-Homed Nodes
Reviewer: Murray S. Kucherawy
Review Date: September 13, 2011
IETF Last Call Date: N/A (not yet in IETF Last Call)
IESG Telechat Date: N/A (not scheduled)
Summary: This draft is almost ready for publication as a Standards Track =
RFC
but has a few issues that should be fixed before publication.

NOTE: This is an early review, so please ignore the parts of this
boilerplate that sound as though you=92re in IETF Last Call.=A0 Also, =
this is a
review of the -03 version of the draft.=A0 A new version was published =
after I
had already completed a good part of my review, so I completed it based =
on
this version and not the new one.=A0 I haven=92t looked at the diffs =
between the
two.

Major Issues:
=95 None.

Minor Issues:
=95 The IANA Considerations section seems to be a little understated. =
=A0I would
suggest copying the one from RFC3646 and modifying it accordingly.

Teemu>Roger that, I updated my -05 candidate IANA considerations section =
to
look following (as of now):
--
   This memo requests IANA to assign two new option codes.  First option
   code is requested to be assigned for DHCPv4 DNS Server Selection
   option (TBD) from the DHCP option code space defined in section "New
   DHCP option codes" of RFC 2939.  Second option code is requested to
   be assigned to the DHCPv6 DNS Server Selection option (TBD) from the
   DHCPv6 option code space defined in section "IANA Considerations" of
   RFC 3315.
--

=95 The use of =93domain=94 in the first paragraph of Section 1 is =
ambiguous.=A0 The
word =93domain=94 is unfortunately overloaded to mean management domain, =
DNS
domain, and probably some others, plus the usual dictionary =
definition.=A0 I
recommend simply saying =93a solution for IPv6.=94=A0 Don=92t be =
surprised if a DNS
Directorate reviewer complains about this as well.

Teemu>It now says:=94=85multi-interfaced nodes and provides a =
solution=94, as the
solution is proposed for both IPv4 and IPv6.

=95 The document in general makes use of the term =93DNS suffix=94.=A0 =
It could be
that I=92ve simply never encountered the term before, but it took me a =
while
of reading to realize this actually meant =93domain name=94.=A0 I would =
suggest
clarifying this up front someplace, or changing it to =93domain name=94
throughout.

Teemu>It was changed to =93domain=94 throughout. However, for section =
4.1 (where
this is introduced) I added further clarification that =93domain=94 is =
referring
to =93DNS domain name suffixes=94:
--
=85..matching to specific DNS domain name suffixes or reverse (PTR =
record)
lookup
          requests matching to specific network addresses (later =
referred as
"domain" and "network").
--

=95 The last paragraph of Section 2.4 is confusing.=A0 It says =93After =
the
interface change[,] a host could have both positive and negative DNS =
cache
entries no longer valid on the new network interface.=94=A0 Should that
=93both=85and=94 be =93either=85or=94?=A0 I=92m not clear on how a =
single node can have both
positive and negative DNS cache entries no longer valid on the new
interface, unless you mean some of its cache will be positive and wrong =
and
some of its cache will be negative and wrong (about different names) =
after
the move.=A0 This should be clarified.

Teemu> Section 2.2..  It tries to say any cached entry may or may not be
valid after interface change =96 as you guessed. How about:
--
A thing worth noting is that network specific IP addresses can cause
problems also for a single-homed node, if the node retains DNS cache =
during
movement from one network to another. After the network change, a node =
may
have both wrong positive and wrong negative entries in its DNS cache.
--

=95 I found it strange to read RFC2119 normative language Section 4.1 =
which
describes an internal-use algorithm for collecting and organizing data
learned from DHCP and DHCPv6 to build up a set of rules for deciding =
which
nameserver(s) to use for which queries.=A0 The same sort of thing =
appeared
later in Sections 4.5 and 4.6.=A0 My understanding is that, since DHCP =
and
DHCPv6 are the wire protocols used and this section describes an
internal-use mechanism, these bits of the text shouldn=92t include any =
RFC2119
language; there is nothing here that affects interoperability between =
two
nodes implementing this protocol.=A0 If a node implementing this gets it
wrong, it only hurts itself; the wire protocols don=92t break.=A0 If =
this
section were to be separated into its own document, it would be
Informational, not Standards Track.=A0 This isn=92t a showstopper for =
me, but I
did find it unusual.

Teemu>The normative text for this algorithm is there mostly due concerns
that otherwise this option could open a new attack vector. By describing =
how
a node MUST handle the information it receives, the risk of attacks =
should
be decreased. The normative text is there also so that if a node claims
compliancy to RFC, network operator who provides such options (to build =
a
system) could expect a node to behave as is described.=20

=95 There are a few places in the document, the Introduction and Section =
4.1
for example, that talk about PTR lookup requests matching specific IPv6
prefixes.=A0 However, the abstract mentions IPv4 support, and the =
mechanism is
also described for IPv4.=A0 I suggest making a quick pass through the =
document
to be sure it doesn=92t appear as if IPv6 is the focus and IPv4 was =
added in
as an after-thought.

Teemu>Well IPv4 was after-thought as I would have settled for IPv6-only =
but
WG wanted IPv4 option as well:-) The -04 version should have cleared =
several
of these "IPv6 focus" issues (by talking about network addresses instead =
of
prefixes), but I guess checking again would not hurt. On the other hand,
IPv6 really is the focus here, as multi-interface behavior with IPv4 =
anyway
is terrible mess due widespread usage of RFC1918 addressed networks (and
that's why I'm secretly hoping DHC WG would say they don=92t want to use =
DHCP
option code for this option and hence this technology must be =
IPv6-only:-D.

=95 The normative language in Section 4.1 around DNSSEC seems to be the =
kind
of thing that should be left for local policy.=A0 I can envision =
environments
where the client isn=92t doing anything sensitive enough to demand =
DNSSEC, so
the first reply it gets from any nameserver it queried is probably =
fine.=A0
The same sort of thing reappears in Section 4.4.

Teemu>This document should already allow such local policy. Section 4.4.
describes possibility of "unless the node is specifically configured to =
do
so.". The DNSSEC requirement has been very hard on MIF WG mailing list
discussions in order to fight against creation of new attack vectors, =
hence
easing that requirement requires restarting of those discussions. See =
also
section 4.4 for cases where DNSSEC is not required - like the option =
1:"The
server selection option is delivered across a secure, trusted channel."

=95 In Section 4.2, the paragraph starting =93If the =
OPTION_DNS_SERVER_SELECT
contains=85=94 was a little confusing to read.=A0 It says in general =
that when
learning about DNS servers available, the node can update what it knows =
but
can=92t forget what it=92s learned, however it can ignore things it =
chooses to
ignore.=A0 I found this difficult to follow.=A0 Some expansion of this
paragraph, perhaps with examples, might help.

Teemu>I wonder if it would be actually wiser just to keep one instance =
of
the option contents in memory (from most trusted network interface?), =
and
ensure all legitimate DHCP servers have the same content for the same =
DNS
server option?

=95 At the end of Section 4.2, it says =93=85use of generic DHCPv6 =
Information
Refresh Time Option, as specified in [RFC4242], is envisaged.=94=A0 That =
wording
is odd; shouldn=92t it be RECOMMENDED?=A0 It=92s too vague otherwise.

Teemu>Fine for me, changed on -05 candidate accordingly.

=95 Section 4.4 says a node MUST NOT use the feature being described =
here
unless specifically configured to do so.=A0 That seems odd.=A0 Is the =
intent to
have implementations force this feature off-by-default?

Teemu>Pretty much so, due security concerns. Please note that other SDOs =
or
organizations that create profiles may say that in their environments =
the
feature shall be on-by-default.

=95 I didn=92t understand this sentence in Section 4.5: =93When both =
options are
received from the same network interface =85, the resolver MUST make the
decision which one to prefer based on preferences.=94

Teemu>modified to:"...decision which one to prefer based on DNS =
preference
field value.". Better?

=95 Section 7 says =93To ensure nodes=92 routing =85 works correctly, =
network
administrators should also deploy related technologies for that =
purpose.=94=A0
Are there any that can be suggested or referenced here?

Teemu>I actually removed that sentence on -04 as it is probably better =
to
tie different solution documents together in some other document (like =
at
draft-ietf-v6ops-ipv6-multihoming-without-ipv6nat ). The reference could
have been to RFC4191 and MIF DHCPv6 route option (at least).
=20
=95 Appendix A is called =93Best Current Practice=94, but the first =
section starts
out =93A possible current practice=85=94=A0 Where=92s the best one, and =
why is it
best?

Teemu>well.. changed title of Appendix A to "Possible alternative =
practices
for DNS server selection". Better?

Nits:
=95 There are a few places where I saw RFC2119 words used in =
non-normative
ways, such as the last sentence of Section 3.1 or the middle of Section =
7.=A0
I would suggest considering alternate words like =93might=94 in place of =
=93may=94
specifically to avoid such issues.

Teemu>You refer to section 7 comment regarding "are recommended to =
avoid..".
The section 7 was completely rewritten for -04 and is now using =
normative
ways. On section 3.1 you refer to "may be considered.."? Changed that to
might. I guess the doc needs reading pass to find possible other =
instances
of this issue...

=95 There=92s a discussion point at the end of Section 4.1 that asks =
=93What about
those DNS servers that instead of a negative answer always return =
positive
reply with an IP address of some captive portal?=94=A0 I don=92t think =
software
implementing this specification can determine that via a DHCP query =
without
other supporting changes to the infrastructure.=A0 I suggest not trying =
to
tackle this point.

Teemu>Thank you for commenting - and also supporting - on this issue. I
thought about this yesterday and also decided not trying to tackle this
point and removed the note from -04.... Node with DNSSEC implementation
would fail on validation on such cases.. but would still have to =
continue in
order to get to the captive portal....

=95 In Section 4.3, Figure 6, the order of =
=93DNS-recusrive-name-server=94 and
=93prf=94 in the description should be swapped to match the order in =
which they
appear in the diagram.

Teemu>Changed

=95 In Section 5, the explanation bullets under Figure 7 include two =
DHCPv6
replies.=A0 The second one covered =93example.com=94 and a specific IPv6 =
suffix,
but it=92s not clear that there was no overlap with the first one (i.e., =
the
first one could=92ve said the same thing).=A0 It should be made clear =
that they
had disjoint replies.

Teemu>Ok.. changed to:
---
   2.  The node obtains domain 'domain1.example.com' and IPv6 network
       '0.8.b.d.0.1.0.0.2.ip6.arpa' for the new interface 1 from DHCPv6
       server
....
   5.  The node obtains domain 'domain2.example.com' and IPv6 network
       information, say '1.8.b.d.0.1.0.0.2.ip6.arpa' for the new
       interface 2 from DHCPv6 server
---=20
and  later in fig 8:
--
   1.  An application makes a request for resolving an FQDN, e.g.
       'private.domain2.example.com'
--

=95 In several places there are references to =93chapters=94 instead of =
=93sections=94
or the =93section=94 reference is not capitalized, which xml2rfc does =
for you.=A0
It seems then these are manual references rather than automatic ones, =
though
the document does claim to have been produced by xml2rfc.=A0=A0 You =
might make
your life easier by changing them to <xref=85> tags.

Teemu>Fixed manually... will try to remember to update to automatic =
later:-D

=95 Section 10 might be improved by dividing separate topics into their =
own
subsections.=A0 For example, the first three paragraphs could become =
Section
10.1, and the remaining two could go in 10.2 and 10.3.

Teemu>I will think about this (now running out of time to do edits while
replying)

=95 Appendix A.1 uses the term =93hotspot=94 which is colloquial and =
might even be
trademarked.=A0 I suggest =93wireless network=94.

Teemu>That part was removed at the same time the text talking about =
leaking
names was removed..

=95 The document is in need of a full edit pass with attention to =
corrections
of English grammar.=20

Teemu>Yep, hopefully by someone who is native English speaker:-) (or
otherwise skilled).

------=_NextPart_000_0158_01CC72FF.21E75F20
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"

------=_NextPart_000_0158_01CC72FF.21E75F20--

From: "Murray S. Kucherawy" <[email-masked]>
To: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Wed, 14 Sep 2011 00:01:22 -0700
Accept-Language: en-US
acceptlanguage: en-US
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: [apps-review] apps-team review of draft-ietf-mif-dns-server-selection

--_000_F5833273385BB34F99288B3648C4F06F13512DFC2AEXCHC2corpclo_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

I have been selected as the Applications Area Review Team reviewer for this=
 draft (for background on apps-review, please see http://www.apps.ietf.org/=
content/applications-area-review-team).

Please resolve these comments along with any other Last Call comments you m=
ay receive. Please wait for direction from your document shepherd or AD bef=
ore posting a new version of the draft.

Document: draft-ietf-mif-dns-server-selection-03
Title: Improved DNS Server Selection for Multi-Homed Nodes
Reviewer: Murray S. Kucherawy
Review Date: September 13, 2011
IETF Last Call Date: N/A (not yet in IETF Last Call)
IESG Telechat Date: N/A (not scheduled)

Summary: This draft is almost ready for publication as a Standards Track RF=
C but has a few issues that should be fixed before publication.

NOTE: This is an early review, so please ignore the parts of this boilerpla=
te that sound as though you're in IETF Last Call.  Also, this is a review o=
f the -03 version of the draft.  A new version was published after I had al=
ready completed a good part of my review, so I completed it based on this v=
ersion and not the new one.  I haven't looked at the diffs between the two.

Major Issues:

*         None.

Minor Issues:

*         The IANA Considerations section seems to be a little understated.=
  I would suggest copying the one from RFC3646 and modifying it accordingly=
.

*         The use of "domain" in the first paragraph of Section 1 is ambigu=
ous.  The word "domain" is unfortunately overloaded to mean management doma=
in, DNS domain, and probably some others, plus the usual dictionary definit=
ion.  I recommend simply saying "a solution for IPv6."  Don't be surprised =
if a DNS Directorate reviewer complains about this as well.

*         The document in general makes use of the term "DNS suffix".  It c=
ould be that I've simply never encountered the term before, but it took me =
a while of reading to realize this actually meant "domain name".  I would s=
uggest clarifying this up front someplace, or changing it to "domain name" =
throughout.

*         The last paragraph of Section 2.4 is confusing.  It says "After t=
he interface change[,] a host could have both positive and negative DNS cac=
he entries no longer valid on the new network interface."  Should that "bot=
h...and" be "either...or"?  I'm not clear on how a single node can have bot=
h positive and negative DNS cache entries no longer valid on the new interf=
ace, unless you mean some of its cache will be positive and wrong and some =
of its cache will be negative and wrong (about different names) after the m=
ove.  This should be clarified.

*         I found it strange to read RFC2119 normative language Section 4.1=
 which describes an internal-use algorithm for collecting and organizing da=
ta learned from DHCP and DHCPv6 to build up a set of rules for deciding whi=
ch nameserver(s) to use for which queries.  The same sort of thing appeared=
 later in Sections 4.5 and 4.6.  My understanding is that, since DHCP and D=
HCPv6 are the wire protocols used and this section describes an internal-us=
e mechanism, these bits of the text shouldn't include any RFC2119 language;=
 there is nothing here that affects interoperability between two nodes impl=
ementing this protocol.  If a node implementing this gets it wrong, it only=
 hurts itself; the wire protocols don't break.  If this section were to be =
separated into its own document, it would be Informational, not Standards T=
rack.  This isn't a showstopper for me, but I did find it unusual.

*         There are a few places in the document, the Introduction and Sect=
ion 4.1 for example, that talk about PTR lookup requests matching specific =
IPv6 prefixes.  However, the abstract mentions IPv4 support, and the mechan=
ism is also described for IPv4.  I suggest making a quick pass through the =
document to be sure it doesn't appear as if IPv6 is the focus and IPv4 was =
added in as an after-thought.

*         The normative language in Section 4.1 around DNSSEC seems to be t=
he kind of thing that should be left for local policy.  I can envision envi=
ronments where the client isn't doing anything sensitive enough to demand D=
NSSEC, so the first reply it gets from any nameserver it queried is probabl=
y fine.  The same sort of thing reappears in Section 4.4.

*         In Section 4.2, the paragraph starting "If the OPTION_DNS_SERVER_=
SELECT contains..." was a little confusing to read.  It says in general tha=
t when learning about DNS servers available, the node can update what it kn=
ows but can't forget what it's learned, however it can ignore things it cho=
oses to ignore.  I found this difficult to follow.  Some expansion of this =
paragraph, perhaps with examples, might help.

*         At the end of Section 4.2, it says "...use of generic DHCPv6 Info=
rmation Refresh Time Option, as specified in [RFC4242], is envisaged."  Tha=
t wording is odd; shouldn't it be RECOMMENDED?  It's too vague otherwise.

*         Section 4.4 says a node MUST NOT use the feature being described =
here unless specifically configured to do so.  That seems odd.  Is the inte=
nt to have implementations force this feature off-by-default?

*         I didn't understand this sentence in Section 4.5: "When both opti=
ons are received from the same network interface ..., the resolver MUST mak=
e the decision which one to prefer based on preferences."

*         Section 7 says "To ensure nodes' routing ... works correctly, net=
work administrators should also deploy related technologies for that purpos=
e."  Are there any that can be suggested or referenced here?

*         Appendix A is called "Best Current Practice", but the first secti=
on starts out "A possible current practice..."  Where's the best one, and w=
hy is it best?

Nits:

*         There are a few places where I saw RFC2119 words used in non-norm=
ative ways, such as the last sentence of Section 3.1 or the middle of Secti=
on 7.  I would suggest considering alternate words like "might" in place of=
 "may" specifically to avoid such issues.

*         There's a discussion point at the end of Section 4.1 that asks "W=
hat about those DNS servers that instead of a negative answer always return=
 positive reply with an IP address of some captive portal?"  I don't think =
software implementing this specification can determine that via a DHCP quer=
y without other supporting changes to the infrastructure.  I suggest not tr=
ying to tackle this point.

*         In Section 4.3, Figure 6, the order of "DNS-recusrive-name-server=
" and "prf" in the description should be swapped to match the order in whic=
h they appear in the diagram.

*         In Section 5, the explanation bullets under Figure 7 include two =
DHCPv6 replies.  The second one covered "example.com" and a specific IPv6 s=
uffix, but it's not clear that there was no overlap with the first one (i.e=
., the first one could've said the same thing).  It should be made clear th=
at they had disjoint replies.

*         In several places there are references to "chapters" instead of "=
sections" or the "section" reference is not capitalized, which xml2rfc does=
 for you.  It seems then these are manual references rather than automatic =
ones, though the document does claim to have been produced by xml2rfc.   Yo=
u might make your life easier by changing them to <xref...> tags.

*         Section 10 might be improved by dividing separate topics into the=
ir own subsections.  For example, the first three paragraphs could become S=
ection 10.1, and the remaining two could go in 10.2 and 10.3.

*         Appendix A.1 uses the term "hotspot" which is colloquial and migh=
t even be trademarked.  I suggest "wireless network".

*         The document is in need of a full edit pass with attention to cor=
rections of English grammar.

--_000_F5833273385BB34F99288B3648C4F06F13512DFC2AEXCHC2corpclo_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=
osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:=
//www.w3.org/TR/REC-html40"><head><meta http-equiv=3DContent-Type content=
=3D"text/html; charset=3Dus-ascii"><meta name=3DGenerator content=3D"Micros=
oft Word 12 (filtered medium)"><style><!--
/* Font Definitions */
@font-face
	{font-family:Wingdings;
	panose-1:5 0 0 0 0 0 0 0 0 0;}
@font-face
	{font-family:"Cambria Math";
	panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
	{font-family:Consolas;
	panose-1:2 11 6 9 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri","sans-serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
pre
	{mso-style-priority:99;
	mso-style-link:"HTML Preformatted Char";
	margin:0in;
	margin-bottom:.0001pt;
	font-size:10.0pt;
	font-family:Consolas;}
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
	{mso-style-priority:34;
	margin-top:0in;
	margin-right:0in;
	margin-bottom:0in;
	margin-left:.5in;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri","sans-serif";}
span.EmailStyle17
	{mso-style-type:personal-compose;
	font-family:"Calibri","sans-serif";
	color:windowtext;}
span.HTMLPreformattedChar
	{mso-style-name:"HTML Preformatted Char";
	mso-style-priority:99;
	mso-style-link:"HTML Preformatted";
	font-family:Consolas;}
.MsoChpDefault
	{mso-style-type:export-only;}
@page WordSection1
	{size:8.5in 11.0in;
	margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
	{page:WordSection1;}
/* List Definitions */
@list l0
	{mso-list-id:1678187230;
	mso-list-type:hybrid;
	mso-list-template-ids:889095734 1831734722 67698691 67698693 67698689 6769=
8691 67698693 67698689 67698691 67698693;}
@list l0:level1
	{mso-level-start-at:2;
	mso-level-number-format:bullet;
	mso-level-text:\F0B7;
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	text-indent:-.25in;
	font-family:Symbol;
	mso-fareast-font-family:Calibri;
	mso-bidi-font-family:"Times New Roman";}
ol
	{margin-bottom:0in;}
ul
	{margin-bottom:0in;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext=3D"edit">
<o:idmap v:ext=3D"edit" data=3D"1" />
</o:shapelayout></xml><![endif]--></head><body lang=3DEN-US link=3Dblue vli=
nk=3Dpurple><div class=3DWordSection1><p class=3DMsoNormal>I have been sele=
cted as the Applications Area Review Team reviewer for this draft (for back=
ground on apps-review, please see <a href=3D"http://www.apps.ietf.org/conte=
nt/applications-area-review-team" title=3D"http://www.apps.ietf.org/content=
/applications-area-review-team">http://www.apps.ietf.org/content/applicatio=
ns-area-review-team</a>).<o:p></o:p></p><p class=3DMsoNormal><br>Please res=
olve these comments along with any other Last Call comments you may receive=
. Please wait for direction from your document shepherd or AD before postin=
g a new version of the draft.<o:p></o:p></p><p class=3DMsoNormal><br>Docume=
nt: draft-ietf-mif-dns-server-selection-03<br>Title: Improved DNS Server Se=
lection for Multi-Homed Nodes<br>Reviewer: Murray S. Kucherawy<br>Review Da=
te: September 13, 2011<br>IETF Last Call Date: N/A (not yet in IETF Last Ca=
ll)<br>IESG Telechat Date: N/A (not scheduled)<br><br><o:p></o:p></p><p cla=
ss=3DMsoNormal>Summary: This draft is almost ready for publication as a Sta=
ndards Track RFC but has a few issues that should be fixed before publicati=
on.<o:p></o:p></p><p class=3DMsoNormal><br>NOTE: This is an early review, s=
o please ignore the parts of this boilerplate that sound as though you&#821=
7;re in IETF Last Call.&nbsp; Also, this is a review of the -03 version of =
the draft.&nbsp; A new version was published after I had already completed =
a good part of my review, so I completed it based on this version and not t=
he new one.&nbsp; I haven&#8217;t looked at the diffs between the two.<o:p>=
</o:p></p><p class=3DMsoNormal><br>Major Issues:<o:p></o:p></p><p class=3DM=
soListParagraph style=3D'text-indent:-.25in;mso-list:l0 level1 lfo1'><![if =
!supportLists]><span style=3D'font-family:Symbol'><span style=3D'mso-list:I=
gnore'>&middot;<span style=3D'font:7.0pt "Times New Roman"'>&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span></span></span><![endif]>None.<o:p>=
</o:p></p><p class=3DMsoNormal><br>Minor Issues:<o:p></o:p></p><p class=3DM=
soListParagraph style=3D'text-indent:-.25in;mso-list:l0 level1 lfo1'><![if =
!supportLists]><span style=3D'font-family:Symbol'><span style=3D'mso-list:I=
gnore'>&middot;<span style=3D'font:7.0pt "Times New Roman"'>&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span></span></span><![endif]>The IANA C=
onsiderations section seems to be a little understated. &nbsp;I would sugge=
st copying the one from RFC3646 and modifying it accordingly.<o:p></o:p></p=
><p class=3DMsoListParagraph style=3D'text-indent:-.25in;mso-list:l0 level1=
 lfo1'><![if !supportLists]><span style=3D'font-family:Symbol'><span style=
=3D'mso-list:Ignore'>&middot;<span style=3D'font:7.0pt "Times New Roman"'>&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span></span></span><![end=
if]>The use of &#8220;domain&#8221; in the first paragraph of Section 1 is =
ambiguous.&nbsp; The word &#8220;domain&#8221; is unfortunately overloaded =
to mean management domain, DNS domain, and probably some others, plus the u=
sual dictionary definition.&nbsp; I recommend simply saying &#8220;a soluti=
on for IPv6.&#8221;&nbsp; Don&#8217;t be surprised if a DNS Directorate rev=
iewer complains about this as well.<o:p></o:p></p><p class=3DMsoListParagra=
ph style=3D'text-indent:-.25in;mso-list:l0 level1 lfo1'><![if !supportLists=
]><span style=3D'font-family:Symbol'><span style=3D'mso-list:Ignore'>&middo=
t;<span style=3D'font:7.0pt "Times New Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp; </span></span></span><![endif]>The document in general=
 makes use of the term &#8220;DNS suffix&#8221;.&nbsp; It could be that I&#=
8217;ve simply never encountered the term before, but it took me a while of=
 reading to realize this actually meant &#8220;domain name&#8221;.&nbsp; I =
would suggest clarifying this up front someplace, or changing it to &#8220;=
domain name&#8221; throughout.<o:p></o:p></p><p class=3DMsoListParagraph st=
yle=3D'text-indent:-.25in;mso-list:l0 level1 lfo1'><![if !supportLists]><sp=
an style=3D'font-family:Symbol'><span style=3D'mso-list:Ignore'>&middot;<sp=
an style=3D'font:7.0pt "Times New Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp; </span></span></span><![endif]>The last paragraph of Sectio=
n 2.4 is confusing.&nbsp; It says &#8220;After the interface change[,] a ho=
st could have both positive and negative DNS cache entries no longer valid =
on the new network interface.&#8221;&nbsp; Should that &#8220;both&#8230;an=
d&#8221; be &#8220;either&#8230;or&#8221;?&nbsp; I&#8217;m not clear on how=
 a single node can have both positive and negative DNS cache entries no lon=
ger valid on the new interface, unless you mean some of its cache will be p=
ositive and wrong and some of its cache will be negative and wrong (about d=
ifferent names) after the move.&nbsp; This should be clarified.<o:p></o:p><=
/p><p class=3DMsoListParagraph style=3D'text-indent:-.25in;mso-list:l0 leve=
l1 lfo1'><![if !supportLists]><span style=3D'font-family:Symbol'><span styl=
e=3D'mso-list:Ignore'>&middot;<span style=3D'font:7.0pt "Times New Roman"'>=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span></span></span><![en=
dif]>I found it strange to read RFC2119 normative language Section 4.1 whic=
h describes an internal-use algorithm for collecting and organizing data le=
arned from DHCP and DHCPv6 to build up a set of rules for deciding which na=
meserver(s) to use for which queries.&nbsp; The same sort of thing appeared=
 later in Sections 4.5 and 4.6.&nbsp; My understanding is that, since DHCP =
and DHCPv6 are the wire protocols used and this section describes an intern=
al-use mechanism, these bits of the text shouldn&#8217;t include any RFC211=
9 language; there is nothing here that affects interoperability between two=
 nodes implementing this protocol.&nbsp; If a node implementing this gets i=
t wrong, it only hurts itself; the wire protocols don&#8217;t break.&nbsp; =
If this section were to be separated into its own document, it would be Inf=
ormational, not Standards Track.&nbsp; This isn&#8217;t a showstopper for m=
e, but I did find it unusual.<o:p></o:p></p><p class=3DMsoListParagraph sty=
le=3D'text-indent:-.25in;mso-list:l0 level1 lfo1'><![if !supportLists]><spa=
n style=3D'font-family:Symbol'><span style=3D'mso-list:Ignore'>&middot;<spa=
n style=3D'font:7.0pt "Times New Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp; </span></span></span><![endif]>There are a few places in the=
 document, the Introduction and Section 4.1 for example, that talk about PT=
R lookup requests matching specific IPv6 prefixes.&nbsp; However, the abstr=
act mentions IPv4 support, and the mechanism is also described for IPv4.&nb=
sp; I suggest making a quick pass through the document to be sure it doesn&=
#8217;t appear as if IPv6 is the focus and IPv4 was added in as an after-th=
ought.<o:p></o:p></p><p class=3DMsoListParagraph style=3D'text-indent:-.25i=
n;mso-list:l0 level1 lfo1'><![if !supportLists]><span style=3D'font-family:=
Symbol'><span style=3D'mso-list:Ignore'>&middot;<span style=3D'font:7.0pt "=
Times New Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span><=
/span></span><![endif]>The normative language in Section 4.1 around DNSSEC =
seems to be the kind of thing that should be left for local policy.&nbsp; I=
 can envision environments where the client isn&#8217;t doing anything sens=
itive enough to demand DNSSEC, so the first reply it gets from any nameserv=
er it queried is probably fine.&nbsp; The same sort of thing reappears in S=
ection 4.4.<o:p></o:p></p><p class=3DMsoListParagraph style=3D'text-indent:=
-.25in;mso-list:l0 level1 lfo1'><![if !supportLists]><span style=3D'font-fa=
mily:Symbol'><span style=3D'mso-list:Ignore'>&middot;<span style=3D'font:7.=
0pt "Times New Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </s=
pan></span></span><![endif]>In Section 4.2, the paragraph starting &#8220;I=
f the OPTION_DNS_SERVER_SELECT contains&#8230;&#8221; was a little confusin=
g to read.&nbsp; It says in general that when learning about DNS servers av=
ailable, the node can update what it knows but can&#8217;t forget what it&#=
8217;s learned, however it can ignore things it chooses to ignore.&nbsp; I =
found this difficult to follow.&nbsp; Some expansion of this paragraph, per=
haps with examples, might help.<o:p></o:p></p><p class=3DMsoListParagraph s=
tyle=3D'text-indent:-.25in;mso-list:l0 level1 lfo1'><![if !supportLists]><s=
pan style=3D'font-family:Symbol'><span style=3D'mso-list:Ignore'>&middot;<s=
pan style=3D'font:7.0pt "Times New Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp; </span></span></span><![endif]>At the end of Section 4.2, =
it says &#8220;&#8230;use of generic DHCPv6 Information Refresh Time Option=
, as specified in [RFC4242], is envisaged.&#8221;&nbsp; That wording is odd=
; shouldn&#8217;t it be RECOMMENDED?&nbsp; It&#8217;s too vague otherwise.<=
o:p></o:p></p><p class=3DMsoListParagraph style=3D'text-indent:-.25in;mso-l=
ist:l0 level1 lfo1'><![if !supportLists]><span style=3D'font-family:Symbol'=
><span style=3D'mso-list:Ignore'>&middot;<span style=3D'font:7.0pt "Times N=
ew Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span></span><=
/span><![endif]>Section 4.4 says a node MUST NOT use the feature being desc=
ribed here unless specifically configured to do so.&nbsp; That seems odd.&n=
bsp; Is the intent to have implementations force this feature off-by-defaul=
t?<o:p></o:p></p><p class=3DMsoListParagraph style=3D'text-indent:-.25in;ms=
o-list:l0 level1 lfo1'><![if !supportLists]><span style=3D'font-family:Symb=
ol'><span style=3D'mso-list:Ignore'>&middot;<span style=3D'font:7.0pt "Time=
s New Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span></spa=
n></span><![endif]>I didn&#8217;t understand this sentence in Section 4.5: =
&#8220;When both options are received from the same network interface &#823=
0;, the resolver MUST make the decision which one to prefer based on prefer=
ences.&#8221;<o:p></o:p></p><p class=3DMsoListParagraph style=3D'text-inden=
t:-.25in;mso-list:l0 level1 lfo1'><![if !supportLists]><span style=3D'font-=
family:Symbol'><span style=3D'mso-list:Ignore'>&middot;<span style=3D'font:=
7.0pt "Times New Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <=
/span></span></span><![endif]>Section 7 says &#8220;To ensure nodes&#8217; =
routing &#8230; works correctly, network administrators should also deploy =
related technologies for that purpose.&#8221;&nbsp; Are there any that can =
be suggested or referenced here?<o:p></o:p></p><p class=3DMsoListParagraph =
style=3D'text-indent:-.25in;mso-list:l0 level1 lfo1'><![if !supportLists]><=
span style=3D'font-family:Symbol'><span style=3D'mso-list:Ignore'>&middot;<=
span style=3D'font:7.0pt "Times New Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp; </span></span></span><![endif]>Appendix A is called &#822=
0;Best Current Practice&#8221;, but the first section starts out &#8220;A p=
ossible current practice&#8230;&#8221;&nbsp; Where&#8217;s the best one, an=
d why is it best?<o:p></o:p></p><p class=3DMsoNormal><o:p>&nbsp;</o:p></p><=
p class=3DMsoNormal>Nits:<o:p></o:p></p><p class=3DMsoListParagraph style=
=3D'text-indent:-.25in;mso-list:l0 level1 lfo1'><![if !supportLists]><span =
style=3D'font-family:Symbol'><span style=3D'mso-list:Ignore'>&middot;<span =
style=3D'font:7.0pt "Times New Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp; </span></span></span><![endif]>There are a few places where I =
saw RFC2119 words used in non-normative ways, such as the last sentence of =
Section 3.1 or the middle of Section 7.&nbsp; I would suggest considering a=
lternate words like &#8220;might&#8221; in place of &#8220;may&#8221; speci=
fically to avoid such issues.<o:p></o:p></p><p class=3DMsoListParagraph sty=
le=3D'text-indent:-.25in;mso-list:l0 level1 lfo1'><![if !supportLists]><spa=
n style=3D'font-family:Symbol'><span style=3D'mso-list:Ignore'>&middot;<spa=
n style=3D'font:7.0pt "Times New Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp; </span></span></span><![endif]>There&#8217;s a discussion po=
int at the end of Section 4.1 that asks &#8220;What about those DNS servers=
 that instead of a negative answer always return positive reply with an IP =
address of some captive portal?&#8221;&nbsp; I don&#8217;t think software i=
mplementing this specification can determine that via a DHCP query without =
other supporting changes to the infrastructure.&nbsp; I suggest not trying =
to tackle this point.<o:p></o:p></p><p class=3DMsoListParagraph style=3D'te=
xt-indent:-.25in;mso-list:l0 level1 lfo1'><![if !supportLists]><span style=
=3D'font-family:Symbol'><span style=3D'mso-list:Ignore'>&middot;<span style=
=3D'font:7.0pt "Times New Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp; </span></span></span><![endif]>In Section 4.3, Figure 6, the order =
of &#8220;DNS-recusrive-name-server&#8221; and &#8220;prf&#8221; in the des=
cription should be swapped to match the order in which they appear in the d=
iagram.<o:p></o:p></p><p class=3DMsoListParagraph style=3D'text-indent:-.25=
in;mso-list:l0 level1 lfo1'><![if !supportLists]><span style=3D'font-family=
:Symbol'><span style=3D'mso-list:Ignore'>&middot;<span style=3D'font:7.0pt =
"Times New Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span>=
</span></span><![endif]>In Section 5, the explanation bullets under Figure =
7 include two DHCPv6 replies.&nbsp; The second one covered &#8220;example.c=
om&#8221; and a specific IPv6 suffix, but it&#8217;s not clear that there w=
as no overlap with the first one (i.e., the first one could&#8217;ve said t=
he same thing).&nbsp; It should be made clear that they had disjoint replie=
s.<o:p></o:p></p><p class=3DMsoListParagraph style=3D'text-indent:-.25in;ms=
o-list:l0 level1 lfo1'><![if !supportLists]><span style=3D'font-family:Symb=
ol'><span style=3D'mso-list:Ignore'>&middot;<span style=3D'font:7.0pt "Time=
s New Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span></spa=
n></span><![endif]>In several places there are references to &#8220;chapter=
s&#8221; instead of &#8220;sections&#8221; or the &#8220;section&#8221; ref=
erence is not capitalized, which xml2rfc does for you.&nbsp; It seems then =
these are manual references rather than automatic ones, though the document=
 does claim to have been produced by xml2rfc.&nbsp;&nbsp; You might make yo=
ur life easier by changing them to &lt;xref&#8230;&gt; tags.<o:p></o:p></p>=
<p class=3DMsoListParagraph style=3D'text-indent:-.25in;mso-list:l0 level1 =
lfo1'><![if !supportLists]><span style=3D'font-family:Symbol'><span style=
=3D'mso-list:Ignore'>&middot;<span style=3D'font:7.0pt "Times New Roman"'>&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span></span></span><![end=
if]>Section 10 might be improved by dividing separate topics into their own=
 subsections.&nbsp; For example, the first three paragraphs could become Se=
ction 10.1, and the remaining two could go in 10.2 and 10.3.<o:p></o:p></p>=
<p class=3DMsoListParagraph style=3D'text-indent:-.25in;mso-list:l0 level1 =
lfo1'><![if !supportLists]><span style=3D'font-family:Symbol'><span style=
=3D'mso-list:Ignore'>&middot;<span style=3D'font:7.0pt "Times New Roman"'>&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span></span></span><![end=
if]>Appendix A.1 uses the term &#8220;hotspot&#8221; which is colloquial an=
d might even be trademarked.&nbsp; I suggest &#8220;wireless network&#8221;=
.<o:p></o:p></p><p class=3DMsoListParagraph style=3D'text-indent:-.25in;mso=
-list:l0 level1 lfo1'><![if !supportLists]><span style=3D'font-family:Symbo=
l'><span style=3D'mso-list:Ignore'>&middot;<span style=3D'font:7.0pt "Times=
 New Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span></span=
></span><![endif]>The document is in need of a full edit pass with attentio=
n to corrections of English grammar. <o:p></o:p></p></div></body></html>=

--_000_F5833273385BB34F99288B3648C4F06F13512DFC2AEXCHC2corpclo_--

Date: Tue, 13 Sep 2011 20:21:28 +0100
From: Dave Cridland <[email-masked]>
To: SM <[email-masked]>, Apps Area Review List <[email-masked]>
Subject: Re: [apps-review] Request for review: draft-ietf-tsvwg-sctpsocket-31

On Tue Sep 13 16:50:31 2011, SM wrote:
> Could you please review draft-ietf-tsvwg-sctpsocket-31 before  
> September 21?

Ack.
-- 
Dave Cridland - mailto:[email-masked] - xmpp:[email-masked]
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade

Date: Tue, 13 Sep 2011 11:09:42 -0700
To: Tim Bray <[email-masked]>
From: SM <[email-masked]>
Cc: [email-masked]
Subject: Re: [apps-review] Request for review: draft-ietf-ecrit-lost-sync-12

Hi Tim,

Could you please take over the review draft-ietf-ecrit-lost-sync-12 
before September 21?

You can find information about the author and WG in the datatracker ( 
https://datatracker.ietf.org/ ).  Some previous reviews from the 
Apps-review Team are accessible at 
http://www.apps.ietf.org/content/apps-review-template

The review should be sent to apps-discuss, the authors, the IESG, the 
WG Chairs and document shepherd, if applicable.

The subject of the email when submitting the review should be 
"apps-team review of" ID-name.

If I don't receive an acknowledgement from you within two days, I'll 
send you a reminder before reassigning the review.

Thanks,
-sm

Date: Tue, 13 Sep 2011 10:43:22 -0700
To: Peter Saint-Andre <[email-masked]>
From: SM <[email-masked]>
Cc: [email-masked]
Subject: Re: [apps-review] Request for review: draft-ietf-ecrit-lost-sync-12

Hi Peter,
At 10:32 13-09-2011, Peter Saint-Andre wrote:
>Carsten has been extremely busy and might not be available right now to
>review this specification.

Thanks, I'll reassign the review to someone else.

Best regards,
-sm 

Date: Tue, 13 Sep 2011 11:32:34 -0600
From: Peter Saint-Andre <[email-masked]>
To: SM <[email-masked]>
OpenPGP: url=https://stpeter.im/stpeter.asc
Cc: [email-masked]
Subject: Re: [apps-review] Request for review: draft-ietf-ecrit-lost-sync-12

Carsten has been extremely busy and might not be available right now to
review this specification.

On 9/13/11 9:42 AM, SM wrote:
> Hi Carsten,
> 
> Could you please review draft-ietf-ecrit-lost-sync-12 before September 21?
> 
> You can find information about the author and WG in the datatracker (
> https://datatracker.ietf.org/ ).  Some previous reviews from the
> Apps-review Team are accessible at
> http://www.apps.ietf.org/content/apps-review-template
> 
> The review should be sent to apps-discuss, the authors, the IESG, the WG
> Chairs and document shepherd, if applicable.
> 
> The subject of the email when submitting the review should be "apps-team
> review of" ID-name.
> 
> If I don't receive an acknowledgement from you within two days, I'll
> send you a reminder before reassigning the review.
> 
> Best regards,
> -sm
> 
> _______________________________________________
> apps-review mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/apps-review

From: "Murray S. Kucherawy" <[email-masked]>
To: SM <[email-masked]>
Date: Tue, 13 Sep 2011 09:36:41 -0700
Accept-Language: en-US
acceptlanguage: en-US
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [apps-review] Request for review: draft-ietf-mif-dns-server-selection-03

> -----Original Message-----
> From: SM [mailto:[email-masked]]
> Sent: Tuesday, September 13, 2011 8:47 AM
> To: Murray S. Kucherawy
> Cc: [email-masked]
> Subject: Request for review: draft-ietf-mif-dns-server-selection-03
>=20
> Hi Murray,
>=20
> Could you please review draft-ietf-mif-dns-server-selection-03 before
> September 21?

Wilco.

Date: Tue, 13 Sep 2011 08:50:31 -0700
To: Dave Cridland <[email-masked]>
From: SM <[email-masked]>
Cc: [email-masked]
Subject: [apps-review] Request for review: draft-ietf-tsvwg-sctpsocket-31

Hi Dave,

Could you please review draft-ietf-tsvwg-sctpsocket-31 before September 21?

You can find information about the author and WG in the datatracker ( 
https://datatracker.ietf.org/ ).  Some previous reviews from the 
Apps-review Team are accessible at 
http://www.apps.ietf.org/content/apps-review-template

The review should be sent to apps-discuss, the authors, the IESG, the 
WG Chairs and document shepherd, if applicable.

The subject of the email when submitting the review should be 
"apps-team review of" ID-name.

If I don't receive an acknowledgement from you within two days, I'll 
send you a reminder before reassigning the review.

Best regards,
-sm

Date: Tue, 13 Sep 2011 08:44:53 -0700
To: Barry Leiba <[email-masked]>
From: SM <[email-masked]>
Cc: [email-masked]
Subject: [apps-review] Request for review: draft-ietf-sidr-ghostbusters-09

Hi Barry,

Could you please review draft-ietf-sidr-ghostbusters-09 before September 21?

You can find information about the author and WG in the datatracker ( 
https://datatracker.ietf.org/ ).  Some previous reviews from the 
Apps-review Team are accessible at 
http://www.apps.ietf.org/content/apps-review-template

The review should be sent to apps-discuss, the authors, the IESG, the 
WG Chairs and document shepherd, if applicable.

The subject of the email when submitting the review should be 
"apps-team review of" ID-name.

If I don't receive an acknowledgement from you within two days, I'll 
send you a reminder before reassigning the review.

Best regards,
-sm

Date: Tue, 13 Sep 2011 08:46:57 -0700
To: "Murray S. Kucherawy" <[email-masked]>
From: SM <[email-masked]>
Cc: [email-masked]
Subject: [apps-review] Request for review: draft-ietf-mif-dns-server-selection-03

Hi Murray,

Could you please review draft-ietf-mif-dns-server-selection-03 before 
September 21?

You can find information about the author and WG in the datatracker ( 
https://datatracker.ietf.org/ ).  Some previous reviews from the 
Apps-review Team are accessible at 
http://www.apps.ietf.org/content/apps-review-template

The review should be sent to apps-discuss, the authors, the IESG, the 
WG Chairs and document shepherd, if applicable.

The subject of the email when submitting the review should be 
"apps-team review of" ID-name.

If I don't receive an acknowledgement from you within two days, I'll 
send you a reminder before reassigning the review.

Best regards,
-sm

Date: Tue, 13 Sep 2011 08:55:15 -0700
To: Ted Hardie <[email-masked]>
From: SM <[email-masked]>
Cc: [email-masked]
Subject: [apps-review] Request for review: draft-ietf-alto-reqs-11

Hi Ted,

Could you please review draft-ietf-alto-reqs-11 before September 21?

You can find information about the author and WG in the datatracker ( 
https://datatracker.ietf.org/ ).  Some previous reviews from the 
Apps-review Team are accessible at 
http://www.apps.ietf.org/content/apps-review-template

The review should be sent to apps-discuss, the authors, the IESG, the 
WG Chairs and document shepherd, if applicable.

The subject of the email when submitting the review should be 
"apps-team review of" ID-name.

If I don't receive an acknowledgement from you within two days, I'll 
send you a reminder before reassigning the review.

Best regards,
-sm

Date: Tue, 13 Sep 2011 09:29:37 -0700
From: Ted Hardie <[email-masked]>
To: SM <[email-masked]>
Cc: [email-masked]
Subject: Re: [apps-review] Request for review: draft-ietf-alto-reqs-11

--20cf303f67c04797f004acd5261f
Content-Type: text/plain; charset=ISO-8859-1

Okay, will do.

Ted

On Tue, Sep 13, 2011 at 8:55 AM, SM <[email-masked]> wrote:

> Hi Ted,
>
> Could you please review draft-ietf-alto-reqs-11 before September 21?
>
> You can find information about the author and WG in the datatracker (
> https://datatracker.ietf.org/ ).  Some previous reviews from the
> Apps-review Team are accessible at http://www.apps.ietf.org/**
> content/apps-review-template<http://www.apps.ietf.org/content/apps-review-template>
>
> The review should be sent to apps-discuss, the authors, the IESG, the WG
> Chairs and document shepherd, if applicable.
>
> The subject of the email when submitting the review should be "apps-team
> review of" ID-name.
>
> If I don't receive an acknowledgement from you within two days, I'll send
> you a reminder before reassigning the review.
>
> Best regards,
> -sm
>
>

--20cf303f67c04797f004acd5261f
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Okay, will do.<div><br></div><div>Ted<br><br><div class=3D"gmail_quote">On =
Tue, Sep 13, 2011 at 8:55 AM, SM <span dir=3D"ltr">&lt;<a href=3D"mailto:sm=
[email-masked]">[email-masked]</a>&gt;</span> wrote:<br><blockq=
uote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc =
solid;padding-left:1ex;">
Hi Ted,<br>
<br>
Could you please review draft-ietf-alto-reqs-11 before September 21?<br>
<br>
You can find information about the author and WG in the datatracker ( <a hr=
ef=3D"https://datatracker.ietf.org/" target=3D"_blank">https://datatracker.=
ietf.org/</a> ). =A0Some previous reviews from the Apps-review Team are acc=
essible at <a href=3D"http://www.apps.ietf.org/content/apps-review-template=
" target=3D"_blank">http://www.apps.ietf.org/<u></u>content/apps-review-tem=
plate</a><br>

<br>
The review should be sent to apps-discuss, the authors, the IESG, the WG Ch=
airs and document shepherd, if applicable.<br>
<br>
The subject of the email when submitting the review should be &quot;apps-te=
am review of&quot; ID-name.<br>
<br>
If I don&#39;t receive an acknowledgement from you within two days, I&#39;l=
l send you a reminder before reassigning the review.<br>
<br>
Best regards,<br><font color=3D"#888888">
-sm<br>
<br>
</font></blockquote></div><br></div>

--20cf303f67c04797f004acd5261f--

Date: Tue, 13 Sep 2011 08:37:18 -0700
To: Xiaodong Lee <[email-masked]>
From: SM <[email-masked]>
Cc: [email-masked]
Subject: [apps-review] Request for review: draft-ietf-behave-v4v6-bih-06

Hi Xiaodong,

Could you please review draft-ietf-behave-v4v6-bih-06 before September 21?

You can find information about the author and WG in the datatracker ( 
https://datatracker.ietf.org/ ).  Some previous reviews from the 
Apps-review Team are accessible at 
http://www.apps.ietf.org/content/apps-review-template

The review should be sent to apps-discuss, the authors, the IESG, the 
WG Chairs and document shepherd, if applicable.

The subject of the email when submitting the review should be 
"apps-team review of" ID-name.

If I don't receive an acknowledgement from you within two days, I'll 
send you a reminder before reassigning the review.

Best regards,
-sm

Date: Tue, 13 Sep 2011 08:42:29 -0700
To: Carsten Bormann <[email-masked]>
From: SM <[email-masked]>
Cc: [email-masked]
Subject: [apps-review] Request for review: draft-ietf-ecrit-lost-sync-12

Hi Carsten,

Could you please review draft-ietf-ecrit-lost-sync-12 before September 21?

You can find information about the author and WG in the datatracker ( 
https://datatracker.ietf.org/ ).  Some previous reviews from the 
Apps-review Team are accessible at 
http://www.apps.ietf.org/content/apps-review-template

The review should be sent to apps-discuss, the authors, the IESG, the 
WG Chairs and document shepherd, if applicable.

The subject of the email when submitting the review should be 
"apps-team review of" ID-name.

If I don't receive an acknowledgement from you within two days, I'll 
send you a reminder before reassigning the review.

Best regards,
-sm

From: "Murray S. Kucherawy" <[email-masked]>
To: "[email-masked]" <[email-masked]>
Date: Thu, 8 Sep 2011 09:21:25 -0700
Accept-Language: en-US
acceptlanguage: en-US
Cc: Apps Review <[email-masked]>
Subject: Re: [apps-review] Review of -- draft-ietf-appsawg-rfc3462bis-00

> -----Original Message-----
> From: Dave CROCKER [mailto:[email-masked]]
> Sent: Thursday, September 08, 2011 6:05 AM
> To: Murray S. Kucherawy
> Cc: Apps Review
> Subject: Review of -- draft-ietf-appsawg-rfc3462bis-00
>=20
> Minor Issues:
>=20
>     Appendix A (Document History) needs a note to the RFC Editor to remov=
e the
> section before publishing.

Fixed.

> Nits:
>=20
>     The document repairs non-normative usage of normative vocabulary, to
> eliminate confusion.  It also changes normative vocabulary to be upper ca=
se, to
> aid detection.  However it appears that some of these changes were
> missed:
>=20
>=20
>  > 3. The multipart/report Media Type
> ...
>  > generated, for a human reader who may not have a user agent
>=20
> may -> might

Fixed.

>  > report.  The text in the first section may be in any MIME
>=20
> may -> MAY   {{ I believe. /d }}

I went with "can"; maybe it's just me, but "MAY" seems to invoke "OR MAY NO=
T" as a test to see if it was properly applied, and it feels like it fails =
here.  (That said, "can" isn't much better, but at least it avoids jabber a=
bout RFC2119 language.)

>  > details not present in the first body part that may be useful to
>=20
> may -> might

Fixed.

>  > Return of content may be wasteful of network bandwidth and a variety
>=20
> may -> can

Fixed.

>  > 4. The text/rfc822-headers Media Type
> ...
>  > to make them legal 7-bit content, they may be encoded with quoted-
>=20
> may -> MAY

Fixed.

>  > 6. Security Considerations
> ...
>  > reports may cause the sender to incorrectly believe a message was
>=20
> may -> can

Fixed.

Thanks for the review!

-MSK

Date: Thu, 08 Sep 2011 06:05:27 -0700
From: Dave CROCKER <[email-masked]>
Organization: Brandenburg InternetWorking
To: Murray Kucherawy <[email-masked]>
Cc: Apps Review <[email-masked]>
Subject: [apps-review] Review of -- draft-ietf-appsawg-rfc3462bis-00
Reply-To: [email-masked]

I've been asked to do an appsarea review of this draft.

Review:

Title:        The Multipart/Report Media Type for the Reporting of Mail System
               Administrative Messages
               draft-ietf-appsawg-rfc3462bis-00

Reviewer:     D. Crocker
Review Date:  8 Sept 11

Summary:

    Multipart/Report is an established format for sending reports.  It is 
defined as a MIME media type, motivated by the need to have a standardized 
format for sending email handling reports.  (After the end of an SMTP transfer 
session, the receiving server still might need to report back to the author or 
originator.  It must send this in an independent email.  This media type 
provides a standardized means of packaging and identifying such reports.)   The 
draft promises a set of minor, non-normative document cleanup changes, and one 
significant normative change, that of removing a restriction on use of the media 
type.

    This change permits the media type to be nested within a MIME structure, 
rather than being limited to the top level.  The restriction was motivated by 
the original, primary usage scenario for email reporting, but has proved 
problematic for other scenarios, including something as simple as forwarding a 
received report(!)

Major Issues:

    None.

    In pedagogical terms, the need for this change demonstrates the important 
difference between documenting a usage restriction that applies only to a 
particular scenario, versus imposing an inherent restriction to the underlying 
data type.  Confusing the two limits utility of the data type.  (Formally, the 
confusion here was between the "packaging" of the data type and the scenario 
usage of the data type.)

Minor Issues:

    Appendix A (Document History) needs a note to the RFC Editor to remove the 
section before publishing.

Nits:

    The document repairs non-normative usage of normative vocabulary, to 
eliminate confusion.  It also changes normative vocabulary to be upper case, to 
aid detection.  However it appears that some of these changes were missed:

 > 3. The multipart/report Media Type
...
 > generated, for a human reader who may not have a user agent

may -> might

 > report.  The text in the first section may be in any MIME

may -> MAY   {{ I believe. /d }}

 > details not present in the first body part that may be useful to

may -> might

 > Return of content may be wasteful of network bandwidth and a variety

may -> can

 > 4. The text/rfc822-headers Media Type
...
 > to make them legal 7-bit content, they may be encoded with quoted-

may -> MAY

 > 6. Security Considerations
...
 > reports may cause the sender to incorrectly believe a message was

may -> can

d/

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

Date: Wed, 07 Sep 2011 17:27:49 -0500
From: "Vijay K. Gurbani" <[email-masked]>
Organization: Bell Laboratories, Alcatel-Lucent
To: [email-masked]
Cc: [email-masked]
Subject: [apps-review] Apps-area review of draft-ietf-p2psip-base-18

I have been selected as the Applications Area Review Team reviewer for 
this draft (for background on apps-review, please see 
http://www.apps.ietf.org/content/applications-area-review-team).

Please resolve these comments along with any other Last Call comments 
you may receive. Please wait for direction from your document shepherd 
or AD before posting a new version of the draft.

Document: draft-ietf-p2psip-base-18
Title: REsource LOcation And Discovery (RELOAD) Base Protocol
Reviewer: Vijay K. Gurbani
Review Date: Sep-7-2011
IETF Last Call Date: Not known
IESG Telechat Date: Sep-8-2011

Summary: This draft is ready for publication as a Proposed Standard.

Major Issues: None.

Minor Issues: 1.

Nits: Few.

Minor Issue:

- In S3.6.1, you may want a forward reference to a later section where
  the well-known server URL is used to fetch the configuration document.

Nits:

- S2, Terminology: Bootstrap node ---
  s/help Nlocate/help locate/

- S2, Connection Table: At this point, "Attach" message
  has not been described.  Maybe a forward reference to S5.5.1 will
  help.

- S2, Destination List ---
  s/A list of IDs/A list of Node-IDs/

- S9, bullet item towards the end of Page 104 ---
  s/(>1000)/(>1000 peers)/

- S9.5, right before S9.6 starts ---
  s/(n+2^(128-i)/(n+2^(128-i))/

Thanks,

- vijay
-- 
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA)
Email: vkg@{bell-labs.com,acm.org} / [email-masked]
Web:   http://ect.bell-labs.com/who/vkg/