Subject: Re: [apps-review] Apps Area Review of: draft-ietf-grow-geomrt-01
From: Dave CROCKER <[email-masked]>
To: Terry Manderson <[email-masked]>
Cc: Christopher Morrow <[email-masked]>, Apps Review <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Wed, 27 Apr 2011 22:05:10 -0700
List-Id: Apps Area Review List <apps-review.ietf.org>

On 4/27/2011 9:51 PM, Terry Manderson wrote:
> A rfcdiff is attached for the new -02 from -01. Do these adequately address
> the issues you raise?

 From a quick read of the diffs, the changes appear to be thorough and complete, 
nevermind the lightning speed with which they were produced.

Nice job.

d/

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

From: Terry Manderson <[email-masked]>
To: Dave CROCKER <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Wed, 27 Apr 2011 21:51:11 -0700
Accept-Language: en-US
acceptlanguage: en-US
Cc: Christopher Morrow <[email-masked]>, Apps Review <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [apps-review] Apps Area Review of: draft-ietf-grow-geomrt-01

--_002_C9DF2F6011ECDterrymandersonicannorg_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi Dave,

Thanks for your careful review.

On 28/04/11 6:17 AM, "Dave CROCKER" <[email-masked]> wrote:

>=20
>=20
> Document:      draft-ietf-grow-geomrt-01
>=20
>=20
>=20
> Major Issues:
>=20
>     0) The specification generally appears reasonable and concise.
> The enhancement seems intuitively useful, although I strongly suggest
> the document make the types of utility explicit.  Why is it good to
> add this information to the table?

I have added a paragraph describing the utility to the introduction.

>=20
>     1) The document presumes extensive background by the
> reader.  Instead it needs a bit of tutorial and it needs to define
> every term -- acronym or core vocabulary -- it uses, either directly
> or by citation

I have added a definitions section.

>=20
>     2) The GEO_PEER_TABLE needs a column with text defining the
> meaning of each value, rather than relying on the labels' being intuitive=
.
>=20

I have added a small table following the GEO_PEER_TABLE and peer entries
defining the label definitions.

>=20
>=20
> Detailed comment:
>=20
>=20
>>  MRT BGP routing information export format with geo-location extensions
>>                      draft-ietf-grow-geomrt-01.txt
>>=20
>> Abstract
>>=20
>>    This document extends the Border Gateway Protocol (BGP) MRT export
>>    format for routing information to include terrestrial coordinates.
>=20
> Expand MRT so that the Abstract requires less background to
> understand and gives a basic sense of the purpose/benefit of this work.

done.
>=20
>=20
>> 2.  Introduction
>>=20
>>    Research is underway that analyzes the network behavior of routing
>>    protocol transactions from routing information base snapshots in
>>    relation to geographical coordinates.  Specifically the BGP routing
>=20
> The first sentence is confusing.  Although I could make guess, I
> don't really know what it means.  I suggest less redundant vocabulary
> and possibly two sentences and probably more active sentence form.
>=20
> In contrast, I find draft-ietf-grow-mrt's related sentence:
>=20
>       "Researchers and engineers often wish to analyze network behavior b=
y
>     studying routing protocol transactions and routing information base
>     snapshots."
>=20
> to be reasonably clear.

Updated.

>=20
>=20
>>    protocol is the subject of study and the analysis has been
>>    significantly aided by the availability and extension of the "MRT
>>    format" [I-D.ietf-grow-mrt] originally defined in the MRT
>>    Programmer's Guide [MRT PROG GUIDE].
>>=20
>>    This memo documents an extension to the "MRT format"
>>    [I-D.ietf-grow-mrt] and introduces an additional definition of a MRT
>>    Subtype field.
>=20
> Lots of acronym repetition, without any acronym definition.

expanded acronyms.

>=20
>=20
>> 3.  Geo-location aware MRT Routing Information Subtype
>>=20
>>    The additional Subtype is defined for the TABLE_DUMP_v format, which
>>    extends the TABLE_DUMP_V2 type.
>>=20
>> 3.1.  GEO_PEER_TABLE
>>=20
>>    The GEO_PEER_TABLE Subtype updates the TABLE_DUMP_v2 Types to include
>>    Geo-location information in the form of WGS84 [WGS 84] formatted
>>    coordinates.  The MRT subtypes would be as follows.
>>=20
>>        1    PEER_INDEX_TABLE
>>        2    RIB_IPV4_UNICAST
>>        3    RIB_IPV4_MULTICAST
>>        4    RIB_IPV6_UNICAST
>>        5    RIB_IPV6_MULTICAST
>>        6    RIB_GENERIC
>>        7    GEO_PEER_TABLE
>=20
> What does each of these value mean?

It's actually superfluous to list types 1-6.

I have updated the table to be just Subtype 7 with a header that explains
that the number is a subtype number and the text is a subtype name.

>=20
> The labels might seem intuitive, but there should be explicit text
> defining their meaning.

They are just the Subtype number and name in the export format. They hold n=
o
special meaning.

>=20
>=20
>>    The GEO_PEER_TABLE MRT record provides the BGP ID of the collector,
>>    Its latitude and longitude in WGS84 [WGS 84] format, and a list of
>>    indexed peers.
>=20
> I'm guessing this is the single most important text in the document,
> since it specifies exactly what location info is being provided.  I
> suggest the Abstract and Introduction summarize this, along the lines of:
>=20
>     ...to include terrestrial coordinates of the BGP collector.

Have updated the intro and abstract.

>=20
> On the other hand, I can't find a definition of what a BGP Collector
> is, in this or related documents.  (It's not in RFC 4271, for
> example.)  In looking over the vocabulary from RFC 4271, it does
> appear that there is no term for the system that receives BGP
> reports.  Clearly one is needed, but it needs to be defined
> explicitly, so please either provide definition text or cite it.0

Indeed no documentation exists describing a BGP collector.
I have added a definition for BGP Collector.

>=20
> In fact, it's probably a good idea to explain why this particular bit
> of information is useful.  A small segment of tutorial text would go
> a long way.
>=20
> Depending on what the definition of a BGP Collector is, the
> usefulness might or might note be obvious, but it shouldn't be left to ch=
ance.

I've provided some expanded information on a BGP Collector in its own
section.

>=20
>=20
>>    The format and function of the Collector BGP ID, Peer Count are as
>>    defined by the TABLE_DUMP_V2 MRT PEER_INDEX_TABLE format.
>>    [I-D.ietf-grow-mrt].
>>=20
>>    The Collector Latitude and Collector Longitude are the geographical
>>    coordinates of the collector in WGS84 [WGS 84] datum decimal degrees
>>    format stored as a single precision float in the 32 bits allocated to
>>    the Collector Latitude and Collector Longitude.  The latitude and
>>    longitude may be a Not A Number (NAN) for situations where the geo-
>=20
> It's not required, but common practice is to capitalize normative
> terms, like MAY.

Fixed.

>=20
>=20
>>    location of the collector is considered private.  The Collector
>>    Latitude and Collector Longitude MUST NOT be a mix of WGS84 [WGS 84]
>>    datum coordinate and NAN values.
>>=20
>>         0                   1                   2                   3
>>    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>    |                      Collector BGP ID                         |
>>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>    |                      Collector Latitude                       |
>>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>    |                      Collector Longitude                      |
>>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>    |          Peer Count           |  Peer entries (variable)
>>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>=20
>>=20
>>=20
>>    The format of the peer entries is shown below.  The Peer Type and the
>>    Peer BGP ID is as defined in the TABLE_DUMP_V2 MRT
>>    [I-D.ietf-grow-mrt] PEER_INDEX_TABLE format.  The order of the Peer
>>    entries in GEO_PEER_TABLE MUST match the order and number as existing
>>    in the PEER_INDEX_TABLE.
>>=20
>>    0                   1                   2                   3
>>    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>    |   Peer Type   |
>>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>    |                         Peer BGP ID                           |
>>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>    |                         Peer Latitude                         |
>>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>    |                         Peer Longitude                        |
>>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>=20
>>=20
>>    The Peer Latitude and Peer Longitude are the geographical coordinates
>>    of the peer in WGS84 [WGS 84] datum decimal degrees format stored as
>>    a single precision float in the 32 bits allocated to the Peer
>>    Latitude and Peer Longitude.  The latitude and longitude may be a Not
>=20
> MAY

fixed

A rfcdiff is attached for the new -02 from -01. Do these adequately address
the issues you raise?

(also noting the removal of the IANA considerations section as the primary
MRT draft no longer calls for an IANA registry, thus geomrt shouldn't
either.)

And I'm awaiting the shepherd's ack to post.

Cheers
Terry

--_002_C9DF2F6011ECDterrymandersonicannorg_
Content-Type: application/octet-stream;
	name="draft-ietf-grow-geomrt-02-from-1.diff.html"
Content-Description: draft-ietf-grow-geomrt-02-from-1.diff.html
Content-Disposition: attachment;
	filename="draft-ietf-grow-geomrt-02-from-1.diff.html"; size=80923;
	creation-date="Wed, 27 Apr 2011 21:51:24 GMT";
	modification-date="Wed, 27 Apr 2011 21:51:24 GMT"
Content-Transfer-Encoding: base64

--_002_C9DF2F6011ECDterrymandersonicannorg_--

From: Eric Burger <[email-masked]>
Date: Wed, 27 Apr 2011 20:36:12 -0400
To: [email-masked]
Cc: Sparks Robert <[email-masked]>, Worley Dale <[email-masked]>
Subject: Re: [apps-review] apps-team review of draft-ietf-speechsc-mrcpv2-24

--Apple-Mail-151--773742168
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

I would offer that after this long and our third editor, the only hope =
for editorial cleanup would be to have professionals do the cleaning, =
i.e., the RFC Editor.

The normative requirements issue is potentially a substantial issue that =
we will look into.

As SM says, Larry has already gone beyond the call of duty given the =
length and detail of this document.

On Apr 27, 2011, at 6:21 PM, SM wrote:

> Hi Larry,
> At 13:30 27-04-2011, Larry Masinter wrote:
>> I'm willing to put more time into reviewing and working with the =
authors if I get feedback that my review comments will be considered.
>=20
> The document contains 221 pages.  I am aware that you have already =
spent eight hours on this assignment.  I could say "thanks for putting =
in more time in the review" as it gets the work done.  Instead, I'll say =
that you have done more work than expected and it is good to consider =
whether the authors and working group will make good use of your =
expertise.
>=20
>> Given that the protocol is already widely implemented interoperabily, =
the goal of getting a "RFC number" shouldn't override completely the =
goal of having a standard of quality for RFCs which rises to the level =
that a RFC can be understood by reading the RFC.
>=20
> Yes, but that's often ignored for the sake of expediency.
>=20
>> I think substantial editorial improvemenet could be made with, oh, a =
week's worth of work on the part of the editors fixing introductory =
material, clearing up references.
>=20
> Ok.
>=20
>> However, the most important thing for moving this document forward =
would be to insure that the normative requirements (MUST, MAY, SHOULD) =
are actually testable or at least determinable, in the path of moving =
the document to Draft Standard.... where each "feature" needs evaluation =
as to mulitple independent interoperable implementations of every =
feature.
>=20
> There aren't a lot of RFCs that move from "Proposed" to "Draft".  Most =
working groups do not get their documents beyond "Proposed".  Convincing =
the IESG that it is worth the effort is not worth the effort. :-)
>=20
> Please go ahead and post the review.
>=20
> Best regards,
> -sm=20
> _______________________________________________
> apps-review mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/apps-review

--Apple-Mail-151--773742168
Content-Disposition: attachment;
	filename=smime.p7s
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Transfer-Encoding: base64

--Apple-Mail-151--773742168--

Date: Wed, 27 Apr 2011 15:21:43 -0700
To: Larry Masinter <[email-masked]>
From: SM <[email-masked]>
Cc: [email-masked]
Subject: Re: [apps-review] apps-team review of draft-ietf-speechsc-mrcpv2-24

Hi Larry,
At 13:30 27-04-2011, Larry Masinter wrote:
>I'm willing to put more time into reviewing and working with the 
>authors if I get feedback that my review comments will be considered.

The document contains 221 pages.  I am aware that you have already 
spent eight hours on this assignment.  I could say "thanks for 
putting in more time in the review" as it gets the work 
done.  Instead, I'll say that you have done more work than expected 
and it is good to consider whether the authors and working group will 
make good use of your expertise.

>Given that the protocol is already widely implemented 
>interoperabily, the goal of getting a "RFC number" shouldn't 
>override completely the goal of having a standard of quality for 
>RFCs which rises to the level that a RFC can be understood by reading the RFC.

Yes, but that's often ignored for the sake of expediency.

>I think substantial editorial improvemenet could be made with, oh, a 
>week's worth of work on the part of the editors fixing introductory 
>material, clearing up references.

Ok.

>However, the most important thing for moving this document forward 
>would be to insure that the normative requirements (MUST, MAY, 
>SHOULD) are actually testable or at least determinable, in the path 
>of moving the document to Draft Standard.... where each "feature" 
>needs evaluation as to mulitple independent interoperable 
>implementations of every feature.

There aren't a lot of RFCs that move from "Proposed" to 
"Draft".  Most working groups do not get their documents beyond 
"Proposed".  Convincing the IESG that it is worth the effort is not 
worth the effort. :-)

Please go ahead and post the review.

Best regards,
-sm 

From: Larry Masinter <[email-masked]>
To: SM <[email-masked]>
Date: Wed, 27 Apr 2011 13:30:27 -0700
Accept-Language: en-US
acceptlanguage: en-US
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [apps-review] apps-team review of draft-ietf-speechsc-mrcpv2-24

I'm willing to put more time into reviewing and working with the authors if=
 I get feedback that my review comments will be considered.

Given that the protocol is already widely implemented interoperabily, the g=
oal of getting a "RFC number" shouldn't override completely the goal of hav=
ing a standard of quality for RFCs which rises to the level that a RFC can =
be understood by reading the RFC.

I think substantial editorial improvemenet could be made with, oh, a week's=
 worth of work on the part of the editors fixing introductory material, cle=
aring up references.

However, the most important thing for moving this document forward would be=
 to insure that the normative requirements (MUST, MAY, SHOULD) are actually=
 testable or at least determinable, in the path of moving the document to D=
raft Standard.... where each "feature" needs evaluation as to mulitple inde=
pendent interoperable implementations of every feature.

Larry
--
http://larry.masinter.net

-----Original Message-----
From: SM [mailto:[email-masked]]=20
Sent: Wednesday, April 27, 2011 10:29 AM
To: Larry Masinter
Cc: [email-masked]
Subject: RE: apps-team review of draft-ietf-speechsc-mrcpv2-24

Hi Larry,

I read your recommendation in the draft review of=20
draft-ietf-speechsc-mrcpv2-24 as "do not publish".  I sent an email=20
to Eric Burger who is the document shepherd.  I haven't received any reply =
yet.

I don't know what the Apps ADs' stance will be on this document.  I=20
can only ask them to read the review and take it into consideration=20
when the document goes through IESG Evaluation.  I hope that you will=20
not be discouraged as documents do get published as RFCs even if they=20
get bad reviews.  In my opinion, your expertise is put to waste as=20
there are people on the apps-discuss mailing list who will read your=20
review and learn something from it.

The following is what I found about draft-ietf-speechsc-mrcpv2:

Document shepherd write-up - June 2009
http://www.ietf.org/mail-archive/web/speechsc/current/msg02386.html

RAI review - June 2009
http://www.ietf.org/mail-archive/web/speechsc/current/msg02396.html

Sec-dir review - July 2010
http://www.ietf.org/mail-archive/web/secdir/current/msg01853.html

In general, I leave it to the author of an Internet-Draft to=20
determine whether a review should be taken as constructive criticism=20
and feedback on how to improve a document or whether it is merely a=20
hurdle to overcome to get that magic RFC number.

Best regards,
-sm

Date: Wed, 27 Apr 2011 13:09:55 -0700
From: Dave CROCKER <[email-masked]>
Organization: Brandenburg InternetWorking
To: Terry Manderson <[email-masked]>
Cc: [email-masked], Apps Review <[email-masked]>
Subject: [apps-review] Apps Area Review of:  draft-ietf-grow-geomrt-01
Reply-To: [email-masked]

Howdy.

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-grow-geomrt-01

Title:         MRT BGP routing information export format with
                geo-location extensions

Reviewer:      D. Crocker <[email-masked]>

Review Date:   27 April 2011

Summary:

    This document provides a focused enhancement to an existing data 
specification for exchanges reports about BGP activity externally.  It adds 
geo-location information to the tables.

Major Issues:

    0) The specification generally appears reasonable and concise. The 
enhancement seems intuitively useful, although I strongly suggest the document 
make the types of utility explicit.  Why is it good to add this information to 
the table?

    1) The document presumes extensive background by the reader.  Instead it 
needs a bit of tutorial and it needs to define every term -- acronym or core 
vocabulary -- it uses, either directly or by citation

    2) The GEO_PEER_TABLE needs a column with text defining the meaning of each 
value, rather than relying on the labels' being intuitive.

Detailed comment:

>  MRT BGP routing information export format with geo-location extensions
>                      draft-ietf-grow-geomrt-01.txt
>
> Abstract
>
>    This document extends the Border Gateway Protocol (BGP) MRT export
>    format for routing information to include terrestrial coordinates.

Expand MRT so that the Abstract requires less background to understand and gives 
a basic sense of the purpose/benefit of this work.

> 2.  Introduction
>
>    Research is underway that analyzes the network behavior of routing
>    protocol transactions from routing information base snapshots in
>    relation to geographical coordinates.  Specifically the BGP routing

The first sentence is confusing.  Although I could make guess, I don't really 
know what it means.  I suggest less redundant vocabulary and possibly two 
sentences and probably more active sentence form.

In contrast, I find draft-ietf-grow-mrt's related sentence:

      "Researchers and engineers often wish to analyze network behavior by
    studying routing protocol transactions and routing information base
    snapshots."

to be reasonably clear.

>    protocol is the subject of study and the analysis has been
>    significantly aided by the availability and extension of the "MRT
>    format" [I-D.ietf-grow-mrt] originally defined in the MRT
>    Programmer's Guide [MRT PROG GUIDE].
>
>    This memo documents an extension to the "MRT format"
>    [I-D.ietf-grow-mrt] and introduces an additional definition of a MRT
>    Subtype field.
>

Lots of acronym repetition, without any acronym definition.

> 3.  Geo-location aware MRT Routing Information Subtype
>
>    The additional Subtype is defined for the TABLE_DUMP_v format, which
>    extends the TABLE_DUMP_V2 type.
>
> 3.1.  GEO_PEER_TABLE
>
>    The GEO_PEER_TABLE Subtype updates the TABLE_DUMP_v2 Types to include
>    Geo-location information in the form of WGS84 [WGS 84] formatted
>    coordinates.  The MRT subtypes would be as follows.
>
>        1    PEER_INDEX_TABLE
>        2    RIB_IPV4_UNICAST
>        3    RIB_IPV4_MULTICAST
>        4    RIB_IPV6_UNICAST
>        5    RIB_IPV6_MULTICAST
>        6    RIB_GENERIC
>        7    GEO_PEER_TABLE

What does each of these value mean?

The labels might seem intuitive, but there should be explicit text defining 
their meaning.

>    The GEO_PEER_TABLE MRT record provides the BGP ID of the collector,
>    Its latitude and longitude in WGS84 [WGS 84] format, and a list of
>    indexed peers.

I'm guessing this is the single most important text in the document, since it 
specifies exactly what location info is being provided.  I suggest the Abstract 
and Introduction summarize this, along the lines of:

    ...to include terrestrial coordinates of the BGP collector.

On the other hand, I can't find a definition of what a BGP Collector is, in this 
or related documents.  (It's not in RFC 4271, for example.)  In looking over the 
vocabulary from RFC 4271, it does appear that there is no term for the system 
that receives BGP reports.  Clearly one is needed, but it needs to be defined 
explicitly, so please either provide definition text or cite it.0

In fact, it's probably a good idea to explain why this particular bit of 
information is useful.  A small segment of tutorial text would go a long way.

Depending on what the definition of a BGP Collector is, the usefulness might or 
might note be obvious, but it shouldn't be left to chance.

>    The format and function of the Collector BGP ID, Peer Count are as
>    defined by the TABLE_DUMP_V2 MRT PEER_INDEX_TABLE format.
>    [I-D.ietf-grow-mrt].
>
>    The Collector Latitude and Collector Longitude are the geographical
>    coordinates of the collector in WGS84 [WGS 84] datum decimal degrees
>    format stored as a single precision float in the 32 bits allocated to
>    the Collector Latitude and Collector Longitude.  The latitude and
>    longitude may be a Not A Number (NAN) for situations where the geo-

It's not required, but common practice is to capitalize normative terms, like MAY.

>    location of the collector is considered private.  The Collector
>    Latitude and Collector Longitude MUST NOT be a mix of WGS84 [WGS 84]
>    datum coordinate and NAN values.
>
>         0                   1                   2                   3
>    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |                      Collector BGP ID                         |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |                      Collector Latitude                       |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |                      Collector Longitude                      |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |          Peer Count           |  Peer entries (variable)
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>
>
>    The format of the peer entries is shown below.  The Peer Type and the
>    Peer BGP ID is as defined in the TABLE_DUMP_V2 MRT
>    [I-D.ietf-grow-mrt] PEER_INDEX_TABLE format.  The order of the Peer
>    entries in GEO_PEER_TABLE MUST match the order and number as existing
>    in the PEER_INDEX_TABLE.
>
>    0                   1                   2                   3
>    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |   Peer Type   |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |                         Peer BGP ID                           |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |                         Peer Latitude                         |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |                         Peer Longitude                        |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>
>    The Peer Latitude and Peer Longitude are the geographical coordinates
>    of the peer in WGS84 [WGS 84] datum decimal degrees format stored as
>    a single precision float in the 32 bits allocated to the Peer
>    Latitude and Peer Longitude.  The latitude and longitude may be a Not

MAY

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

Date: Wed, 27 Apr 2011 10:28:44 -0700
To: Larry Masinter <[email-masked]>
From: SM <[email-masked]>
Cc: [email-masked]
Subject: Re: [apps-review] apps-team review of draft-ietf-speechsc-mrcpv2-24

Hi Larry,

I read your recommendation in the draft review of 
draft-ietf-speechsc-mrcpv2-24 as "do not publish".  I sent an email 
to Eric Burger who is the document shepherd.  I haven't received any reply yet.

I don't know what the Apps ADs' stance will be on this document.  I 
can only ask them to read the review and take it into consideration 
when the document goes through IESG Evaluation.  I hope that you will 
not be discouraged as documents do get published as RFCs even if they 
get bad reviews.  In my opinion, your expertise is put to waste as 
there are people on the apps-discuss mailing list who will read your 
review and learn something from it.

The following is what I found about draft-ietf-speechsc-mrcpv2:

Document shepherd write-up - June 2009
http://www.ietf.org/mail-archive/web/speechsc/current/msg02386.html

RAI review - June 2009
http://www.ietf.org/mail-archive/web/speechsc/current/msg02396.html

Sec-dir review - July 2010
http://www.ietf.org/mail-archive/web/secdir/current/msg01853.html

In general, I leave it to the author of an Internet-Draft to 
determine whether a review should be taken as constructive criticism 
and feedback on how to improve a document or whether it is merely a 
hurdle to overcome to get that magic RFC number.

Best regards,
-sm

Date: Sun, 24 Apr 2011 07:41:12 -0700
To: Alexey Melnikov <[email-masked]>
From: SM <[email-masked]>
Cc: [email-masked]
Subject: Re: [apps-review] Request for review: draft-ietf-sidr-roa-format-10

Hi Alexey,
At 03:28 24-04-2011, Alexey Melnikov wrote:
>Ok, I will take it. But I still want to enjoy the rest of my 5 
>months holidays from the Apps review team after that ;-).

Thanks for doing the review.  You'll get six months of holidays from 
the Apps review team after this. :-)

Best regards,
-sm 

Date: Sun, 24 Apr 2011 11:28:35 +0100
From: Alexey Melnikov <[email-masked]>
To: SM <[email-masked]>
Cc: [email-masked]
Subject: Re: [apps-review] Request for review: draft-ietf-sidr-roa-format-10

SM wrote:

> Hi Alexey,
>
> Would you be able to review draft-ietf-sidr-roa-format-10?  It is due 
> before April 28.

Ok, I will take it. But I still want to enjoy the rest of my 5 months 
holidays from the Apps review team after that ;-).

From: "Murray S. Kucherawy" <[email-masked]>
To: SM <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Thu, 21 Apr 2011 14:52:48 -0700
Accept-Language: en-US
acceptlanguage: en-US
Subject: Re: [apps-review] Request for review: draft-ietf-sieve-external-lists-07

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] =
On Behalf Of SM
> Sent: Thursday, April 21, 2011 2:03 PM
> To: [email-masked]
> Subject: [apps-review] Request for review: draft-ietf-sieve-external-list=
s-07
>=20
> The review of draft-ietf-sieve-external-lists-07 has been assigned to
> you and is due before May 4.

Roger.

-MSK

Date: Thu, 21 Apr 2011 14:18:38 -0700
From: Ted Hardie <[email-masked]>
To: SM <[email-masked]>
Cc: [email-masked]
Subject: Re: [apps-review] Request for review: draft-ietf-sidr-rpki-manifests-10

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

Hi,

Okay, I will have it ready.

regards,

Ted

On Thu, Apr 21, 2011 at 1:45 PM, SM <[email-masked]> wrote:

> Hi Ted,
>
> The review of draft-ietf-sidr-rpki-manifests-10 has been reassigned to you
> and is due before April 28.
>
> You can find information about the author and WG in the datatracker (
> https://datatracker.ietf.org/doc/draft-ietf-sidr-rpki-manifests/ ).  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
> draft-ietf-sidr-rpki-manifests-10".
>
> 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
>
>

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

Hi,<br><br>Okay, I will have it ready.<br><br>regards,<br><br>Ted<br><br><d=
iv class=3D"gmail_quote">On Thu, Apr 21, 2011 at 1:45 PM, SM <span dir=3D"l=
tr">&lt;<a href=3D"mailto:[email-masked]">[email-masked]</a>&=
gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin: 0pt 0pt 0pt 0.8ex; borde=
r-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">Hi Ted,<br>
<br>
The review of draft-ietf-sidr-rpki-manifests-10 has been reassigned to you =
and is due before April 28.<br>
<br>
You can find information about the author and WG in the datatracker ( <a hr=
ef=3D"https://datatracker.ietf.org/doc/draft-ietf-sidr-rpki-manifests/" tar=
get=3D"_blank">https://datatracker.ietf.org/doc/draft-ietf-sidr-rpki-manife=
sts/</a> ). =A0Some previous reviews from the Apps-review Team are accessib=
le at <a href=3D"http://www.apps.ietf.org/content/apps-review-template" tar=
get=3D"_blank">http://www.apps.ietf.org/content/apps-review-template</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<br>
draft-ietf-sidr-rpki-manifests-10&quot;.<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>

--bcaec5314709f2860104a17448d0--

Date: Thu, 21 Apr 2011 14:02:45 -0700
To: [email-masked]
From: SM <[email-masked]>
Subject: [apps-review] Request for review: draft-ietf-sieve-external-lists-07

Hi Murray,

I forgot to Cc apps-review.

The review of draft-ietf-sieve-external-lists-07 has been assigned to 
you and is due before May 4.

You can find information about the author and WG in the datatracker ( 
https://datatracker.ietf.org/doc/draft-ietf-sieve-external-lists/ 
).  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
draft-ietf-sieve-external-lists-07".

Best regards,
-sm

Date: Thu, 21 Apr 2011 13:45:36 -0700
To: Ted Hardie <[email-masked]>
From: SM <[email-masked]>
Cc: [email-masked]
Subject: [apps-review] Request for review: draft-ietf-sidr-rpki-manifests-10

Hi Ted,

The review of draft-ietf-sidr-rpki-manifests-10 has been reassigned 
to you and is due before April 28.

You can find information about the author and WG in the datatracker ( 
https://datatracker.ietf.org/doc/draft-ietf-sidr-rpki-manifests/ 
).  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
draft-ietf-sidr-rpki-manifests-10".

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: Thu, 21 Apr 2011 13:54:07 -0700
To: Alexey Melnikov <[email-masked]>
From: SM <[email-masked]>
Cc: [email-masked]
Subject: [apps-review] Request for review: draft-ietf-sidr-roa-format-10

Hi Alexey,

Would you be able to review draft-ietf-sidr-roa-format-10?  It is due 
before April 28.

Best regards,
-sm

Date: Thu, 21 Apr 2011 09:28:12 -0700
From: Dave CROCKER <[email-masked]>
Organization: Brandenburg InternetWorking
To: Apps Review <[email-masked]>
Subject: [apps-review] IAB draft: Architectural Considerations on Application Features in the DNS
Reply-To: [email-masked]

Folks,

The IAB has a draft it is developing concerning:

    Architectural Considerations on Application Features in the DNS
    I-D: draft-iab-dns-applications-01

I did an unsolicited review of it and posted it to the IETF list:

<https://www.ietf.org/ibin/c5i?mid=6&rid=49&gid=0&k1=933&k2=56220&tid=1303403026>

Since this draft specifically targets applications' use of the DNS, I thought it 
worth suggesting that folks who do apps-related reviews should consider 
discussing the IAB draft on the IETF list.

d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

Date: Thu, 21 Apr 2011 09:20:17 -0700
To: [email-masked]
From: SM <[email-masked]>
Cc: Barry Leiba <[email-masked]>
Subject: Re: [apps-review] [sieve] I-D Action:draft-ietf-sieve-external-lists-07.txt

At 07:54 21-04-2011, Barry Leiba wrote:
> >        Title           : Sieve Extension: Externally Stored Lists
> >        Author(s)       : A. Melnikov, B. Leiba
> >        Filename        : draft-ietf-sieve-external-lists-07.txt
> >        Pages           : 15
> >        Date            : 2011-04-21
>...
> > A URL for this Internet-Draft is:
> > http://www.ietf.org/internet-drafts/draft-ietf-sieve-external-lists-07.txt
>
>This version has all the changes from WGLC comments, and is ready to
>go to the IESG.  Will the chairs please do a PROTO write-up and send
>it on?  SM, will you please assign an apps review team member who does
>not already participate in Sieve to do a review?

Yes.

I am sending the request to the apps-review mailing list as there is 
a logistical problem.  Alexey, Dave Cridland and you are struck off 
the list of possible reviewers as you contributed to 
draft-ietf-sieve-external-lists.  I cannot assign the review to Aaron 
as he is the WG Chair.  I generally avoid assigning a review to 
someone with the same affiliation as the author of the I-D.

Can members of the apps-review team please take a look at 
draft-ietf-sieve-external-lists and email me if they can take on the 
assignment?

Best regards,
-sm 

From: Joseph Yee <[email-masked]>
Date: Tue, 19 Apr 2011 13:34:16 -0400
To: SM <[email-masked]>
Cc: [email-masked]
Subject: Re: [apps-review] Reminder: Request for review: draft-ietf-dime-extended-naptr-06

On 2011-04-19, at 5:36 AM, SM wrote:

> Hi Julian, Joseph,
> At 01:58 19-04-2011, Julian Reschke wrote:
>> I can do a fully mechanical check (ABNF, references, keywords, etc), =
but I do not have *any* knowledge about the technical matter. I'll do =
what I can today, but maybe somebody else can take over with the =
remainder?
>=20
> Can you do the mechanical checks?
>=20
> Joseph, can you do the rest of the review?  I would have done the DDDS =
part if I had the time over the next few days.  If you don't have the =
time, I'll do it as it is less effort than finding another reviewer for =
the assignment.

I will review the rest.  Will work with Julian to combine review report.

Joseph

>=20
> I suggest that you do a joint review if both of you accept the =
assignment.
>=20
> Best regards,
> -sm=20

Date: Tue, 19 Apr 2011 08:55:30 -0700
From: Dave CROCKER <[email-masked]>
Organization: Brandenburg InternetWorking
To: [email-masked]
Subject: Re: [apps-review] Request for review: draft-ietf-grow-geomrt-01
Reply-To: [email-masked]

ack.

d/

On 4/18/2011 10:48 PM, SM wrote:
> The review of draft-ietf-grow-geomrt-01 has been reassigned to you and is due
> before April 29.
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

Date: Tue, 19 Apr 2011 17:55:30 +0200
From: Julian Reschke <[email-masked]>
To: SM <[email-masked]>
Cc: [email-masked]
Subject: Re: [apps-review] Reminder: Request for review: draft-ietf-dime-extended-naptr-06

On 19.04.2011 11:36, SM wrote:
> Hi Julian, Joseph,
> At 01:58 19-04-2011, Julian Reschke wrote:
>> I can do a fully mechanical check (ABNF, references, keywords, etc),
>> but I do not have *any* knowledge about the technical matter. I'll do
>> what I can today, but maybe somebody else can take over with the
>> remainder?
>
> Can you do the mechanical checks?

Done.

All I have is:

-- snip --
Editorial:

        iana-registered-service = aaa-service / ALPHA *31ALPHANUMSYM
        aaa-service             = "aaa+ap" appln-id
        appln-id                = DIGIT *DIGIT
                                  ; Application identifier expressed as a
                                  ; decimal integer.

1) Is "aaa+ap" case-insensitive? (That's the ABNF default for string 
literals)

2) Maybe "1*DIGIT" instead of "DIGIT *DIGIT"?

        iana-registered-protocol = aaa-protocol / ALPHA *31ALPHANUMSYM
        aaa-protocol             = "diameter." aaa-transport
        aaa-transport            = "tcp" / "sctp" / "tls.tcp"

(see above re case-sensitity)
-- snip --

(the ABNF and the references seem to be ok, but as I said; I really did 
only a mechanical check).

> Joseph, can you do the rest of the review? I would have done the DDDS
> part if I had the time over the next few days. If you don't have the
> time, I'll do it as it is less effort than finding another reviewer for
> the assignment.
>
> I suggest that you do a joint review if both of you accept the assignment.

Best regards, Julian

Date: Tue, 19 Apr 2011 02:36:42 -0700
To: Julian Reschke <[email-masked]>, Joseph Yee <[email-masked]>
From: SM <[email-masked]>
Cc: [email-masked]
Subject: Re: [apps-review] Reminder: Request for review: draft-ietf-dime-extended-naptr-06

Hi Julian, Joseph,
At 01:58 19-04-2011, Julian Reschke wrote:
>I can do a fully mechanical check (ABNF, references, keywords, etc), 
>but I do not have *any* knowledge about the technical matter. I'll 
>do what I can today, but maybe somebody else can take over with the remainder?

Can you do the mechanical checks?

Joseph, can you do the rest of the review?  I would have done the 
DDDS part if I had the time over the next few days.  If you don't 
have the time, I'll do it as it is less effort than finding another 
reviewer for the assignment.

I suggest that you do a joint review if both of you accept the assignment.

Best regards,
-sm 

Date: Tue, 19 Apr 2011 10:58:36 +0200
From: Julian Reschke <[email-masked]>
To: SM <[email-masked]>
Cc: [email-masked]
Subject: Re: [apps-review] Reminder: Request for review: draft-ietf-dime-extended-naptr-06

On 18.04.2011 17:24, SM wrote:
> Hi Julian,
>
> The review of draft-ietf-dime-extended-naptr-06 has been assigned to you
> and is due before April 20.
>
> You can find information about the author and WG in the datatracker (
> https://datatracker.ietf.org/doc/draft-ietf-dime-extended-naptr/ ). 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.
> ...

I can do a fully mechanical check (ABNF, references, keywords, etc), but 
I do not have *any* knowledge about the technical matter. I'll do what I 
can today, but maybe somebody else can take over with the remainder?

Best regards, Julian

Date: Mon, 18 Apr 2011 22:48:41 -0700
To: Dave Crocker <[email-masked]>
From: SM <[email-masked]>
Cc: [email-masked]
Subject: [apps-review] Request for review: draft-ietf-grow-geomrt-01

Hi Dave,

The review of draft-ietf-grow-geomrt-01 has been reassigned to you 
and is due before April 29.

You can find information about the author and WG in the datatracker ( 
https://datatracker.ietf.org/doc/draft-ietf-grow-geomrt/ ).  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
draft-ietf-grow-geomrt-01".

Best regards,
-sm

Date: Mon, 18 Apr 2011 22:46:31 -0700
To: Claudio Allocchio <[email-masked]>
From: SM <[email-masked]>
Cc: [email-masked]
Subject: [apps-review] Request for review: draft-ietf-sidr-rpki-manifests-10

Hi Claudio,

The review of draft-ietf-sidr-rpki-manifests-10 has been reassigned 
to you and is due before April 28.

You can find information about the author and WG in the datatracker ( 
https://datatracker.ietf.org/doc/draft-ietf-sidr-rpki-manifests/ 
).  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
draft-ietf-sidr-rpki-manifests-10".

Best regards,
-sm

Date: Mon, 18 Apr 2011 17:57:30 -0700
To: Dave Cridland <[email-masked]>
From: SM <[email-masked]>
Cc: [email-masked]
Subject: [apps-review] Reminder: Request for review: draft-ietf-grow-geomrt-01

Hi Dave,

[Cc to Alexey in case my message is not delivered to your mailbox]

The review of draft-ietf-grow-geomrt-01 has been assigned to you and 
is due before April 29.

You can find information about the author and WG in the datatracker ( 
https://datatracker.ietf.org/doc/draft-ietf-grow-geomrt/ ).  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
draft-ietf-grow-geomrt-01".

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

Best regards,
-sm

Sender: [email-masked]
Date: Mon, 18 Apr 2011 12:59:38 -0400
From: Barry Leiba <[email-masked]>
To: [email-masked], [email-masked]
Cc: [email-masked], [email-masked], [email-masked]
Subject: [apps-review] secdir/apps-area/last-call review of draft-ietf-vcarddav-vcardrev-19

This is a "triple-play" review -- I've been asked to review
draft-ietf-vcarddav-vcardrev-19 by the security directorate and the
applications area review team, and I'd planned to do my own review as
well.

SECDIR boilerplate:
I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG.  These comments were written primarily for the benefit of the
security area directors.  Document editors and WG chairs should treat
these comments just like any other last call comments.

APPS-REVIEW boilerplate:
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.

My plat du jour:
I should note that I've participated in the vcarddav working group,
and have made comments on and contributed text to this document.  That
said, I'm looking at this with a "from scratch" mind, to be sure I'm
considering things afresh.

General comments:

The document is pretty much ready to ship.  The comments I make below
are minor, non-controversial, and easily fixed.  This is a mature spec
that's had quite a lot of review already.  Also, I see no
security-related issues with the document.

Reviewers of the companion document, draft-ietf-vcarddav-vcardxml,
will have to make sure the properties and parameters match up
correctly.  There is a general issue that this "legacy" vCard format
does not have a hierarchy that allows nested elements, which limits
its extensibility somewhat.  The working group did consider whether to
abandon this format in favour of using XML *only* for v4.0, and that
was deemed infeasible: there remains extensive use of this format, and
it needs to be retained, at least for now.

Specific comments:

------------------------------
   3.1.  Character Set

   The character set for vCard is UTF-8 as defined in [RFC3629].  There
   is no way to override this.  It is invalid to specify a different
   character set in the "charset" MIME parameter (see Section 10.1).

This isn't consistent with section 10.1.  UTF-8 is an encoding, not a
character set.  Section 10.1 says this, in reference to parameters on
the media type:

      "charset": as defined for text/plain [RFC2046]; encodings other
      than UTF-8 [RFC3629] MUST NOT be used.

That is the correct characterization.  The problem is that this is
used inconsistently in general, and there's been an extended
controversy in EAI about this very thing.  RFC 3536 specifies
internationalization terminology, and that's currently being updated
by draft-hoffman-rfc3536bis.  From that document:

   charset

      A charset is a method of mapping a sequence of octets to a
      sequence of abstract characters.  A charset is, in effect, a
      combination of one or more CCSs with a CES.  Charset names are
      registered by the IANA according to procedures documented in
      [RFC2978]. <NONE>

      Many protocol definitions use the term "character set" in their
      descriptions.  The terms "charset" or "character encoding scheme"
      and "coded character set" are strongly preferred over the term
      "character set" because "character set" has other definitions in
      other contexts and this can be confusing.

I suggest re-wording 3.1 thus (and an informative reference to RFC
3536 would be reasonable):

NEW
   3.1.  Charset

   The charset [see RFC3536 for internationalization terminology] for vCard
   is UTF-8 as defined in [RFC3629].  There is no way to override this.  It is
   invalid to specify a value other than "UTF-8" in the "charset" MIME
   parameter (see Section 10.1).
------------------------------

   3.3.  ABNF Format Definition

OLD
     ; When parsing a content line, folded lines must first
     ; be unfolded according to the unfolding procedure
     ; described above.
     ; When generating a content line, lines longer than 75
     ; characters SHOULD be folded according to the folding
     ; procedure described above.

NEW
     ; When parsing a content line, folded lines must first
     ; be unfolded according to the unfolding procedure
     ; described in section 3.2.
     ; When generating a content line, lines longer than 75
     ; characters SHOULD be folded according to the folding
     ; procedure described in section 3.2.

OLD
   A line that begins with a white space character is a continuation of
   the previous line, as described above.

NEW
   A line that begins with a white space character is a continuation of
   the previous line, as described in section 3.2.
------------------------------

Section 3.3 says this:
   Parameter values
   MAY be case sensitive or case insensitive, depending on their
   definition.  Based on experience with vCard 3 interoperability, it is
   RECOMMENDED that property and parameter names be upper-case on
   output.

Some of the parameter definitions ("value" (5.2) and "type" (5.6), for
example) use text strings for their values, and give no guidance on
case.  I suggest changing the paragraph in section 3.3:

NEW
   Parameter values
   MAY be case-sensitive or case-insensitive, depending on their
   definitions.  Parameter values that are not explicitly defined
   as being case-sensitive are case-insensitive. Based on
   experience with vCard 3 interoperability, it is RECOMMENDED
   that property names and parameter names be upper-case on output.

------------------------------

3.4. Property Value Escaping

OLD
   Finally, BACKSLASH characters in values MUST be escaped with a
   BACKSLASH character.  NEWLINE (ASCII decimal 10) characters in values
   MUST be encoded by two characters: a BACKSLASH followed by an 'n'
   (ASCII decimal 110).

This is inconsistent with section 4.1.

NEW
   Finally, BACKSLASH characters in values MUST be escaped with a
   BACKSLASH character.  NEWLINE (ASCII decimal 10) characters in values
   MUST be encoded by two characters: a BACKSLASH followed by either an
   'n' (ASCII decimal 110) or an 'N' (ASCII decimal 78).
------------------------------

   4.5.  INTEGER

I note that the ABNF allows "-0" (and, in fact, "-00000000") as a
valid integer.  If that's intended, that's fine; I just wanted to
point it out.
------------------------------

5.9.  SORT-AS

Is this parameter value intended to be case-sensitive?  I think so,
and that should be specified.  Let's fix the "less/fewer" error, while
we're here.

OLD
   This parameter's value is a comma-separated list which MUST have as
   many or less elements as the corresponding property value has
   components.

NEW
   This parameter's value is a comma-separated list which MUST have as
   many or fewer elements as the corresponding property value has
   components.  This parameter's value is case-sensitive.
------------------------------

   6.3.1.  ADR

   Special notes:  The structured type value consists of a sequence of
      address components.  The component values MUST be specified in
      their corresponding position.  The structured type value
      corresponds, in sequence, to the post office box; the extended
      address (e.g. apartment or suite number); the street address; the
      locality (e.g., city); the region (e.g., state or province); the
      postal code; the country name (full name in the language specified
      in Section 5.1).  When a component value is missing, the
      associated component separator MUST still be specified.

SUGGESTION:
I think this would be easier to read and get right as a compact list,
rather than as a paragraph of text.  Maybe like this:

NEW
   Special notes:  The structured type value consists of a sequence of
      address components.  The component values MUST be specified in
      their corresponding position.  The structured type value
      corresponds, in sequence, to
         the post office box;
         the extended address (e.g. apartment or suite number);
         the street address;
         the locality (e.g., city);
         the region (e.g., state or province);
         the postal code;
         the country name (full name in the language specified in
            Section 5.1).
      When a component value is missing, the associated component
      separator MUST still be specified.
------------------------------

   8.  Example: Authors' vCards

There's nothing wrong with leaving Pete Resnick's vCard in there as an
example, but I'll point out that he hasn't been a document editor
since -16 was posted.  I'll also point out that these are not
"authors", but "editors".  Just sayin'....
------------------------------

   9.  Security Considerations

I believe the specified security considerations are adequate, and I
have no issues with them.
------------------------------

   10.1.  MIME Type Registration

   Person & email address to contact for further information:  Simon
      Perreault <[email-masked]>

Section 10.2.1 specifies the creation of a mailing list,
<[email-masked]>.  Perhaps that should be the contact email address
for the MIME type registration as well.
------------------------------

   10.2.1.  Registration Procedure

Nit: change "Standard Tracks RFC" to "Standards Track RFC", throughout.
------------------------------

That's all....

Barry

Date: Mon, 18 Apr 2011 08:42:09 -0700
To: Enrico Marocco <[email-masked]>
From: SM <[email-masked]>
Cc: [email-masked]
Subject: [apps-review] Reminder: Request for review: draft-ietf-avtext-multicast-acq-rtcp-xr-04

Hi Enrico,

I am resending the message below as your mailbox was full this weekend.

The review of draft-ietf-avtext-multicast-acq-rtcp-xr-04 has been 
assigned to you and is due before April 26.

You can find information about the author and WG in the datatracker ( 
https://datatracker.ietf.org/doc/draft-ietf-avtext-multicast-acq-rtcp-xr/ 
).  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
draft-ietf-avtext-multicast-acq-rtcp-xr-04".

Best regards,
-sm

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

Date: Mon, 18 Apr 2011 08:24:32 -0700
To: Julian Reschke <[email-masked]>
From: SM <[email-masked]>
Cc: [email-masked]
Subject: [apps-review] Reminder: Request for review: draft-ietf-dime-extended-naptr-06

Hi Julian,

The review of draft-ietf-dime-extended-naptr-06 has been assigned to 
you and is due before April 20.

You can find information about the author and WG in the datatracker ( 
https://datatracker.ietf.org/doc/draft-ietf-dime-extended-naptr/ 
).  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
draft-ietf-dime-extended-naptr-06".

Please see the message posted at 
http://www.ietf.org/mail-archive/web/apps-review/current/msg00495.html.

Best regards,
-sm

To: SM <[email-masked]>
From: [email-masked] (Henry S. Thompson)
Date: Mon, 18 Apr 2011 14:14:11 +0100
Cc: [email-masked]
Subject: Re: [apps-review] Request for review: draft-ietf-xcon-ccmp-12

=2D----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

SM writes:

> The review of draft-ietf-xcon-ccmp-12 has been assigned to you and is
> due before April 28.

Will do.

ht
=2D --=20
       Henry S. Thompson, School of Informatics, University of Edinburgh
      10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440
                Fax: (44) 131 651-1426, e-mail: [email-masked]
                       URL: http://www.ltg.ed.ac.uk/~ht/
 [mail from me _always_ has a .sig like this -- mail without it is forged s=
pam]
=2D----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)

iD8DBQFNrDkjkjnJixAXWBoRAjsrAJ9vQbvSvYbXjTTlcrRXto/+qqgFaACdHb2n
Q6JaP9onwn8XnVvu0FCAcXA=3D
=3DKd2q
=2D----END PGP SIGNATURE-----

Date: Sat, 16 Apr 2011 05:02:37 -0700
To: Xiaodong Lee <[email-masked]>
From: SM <[email-masked]>
Cc: [email-masked]
Subject: [apps-review] Request for review: draft-ietf-mif-current-practices-09

Hi Xiaodong,

The review of draft-ietf-mif-current-practices-09 has been assigned 
to you and is due before April 28.

You can find information about the author and WG in the datatracker ( 
https://datatracker.ietf.org/doc/draft-ietf-mif-current-practices/ 
).  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
draft-ietf-mif-current-practices-09".

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

Best regards,
-sm

Date: Sat, 16 Apr 2011 05:07:53 -0700
To: Scott Lawrence <[email-masked]>
From: SM <[email-masked]>
Cc: [email-masked]
Subject: [apps-review] Request for review: draft-daboo-et-al-icalendar-in-xml-08

Hi Scott,

The review of draft-daboo-et-al-icalendar-in-xml-08 has been assigned 
to you and is due before May 12.

You can find information about the author and WG in the datatracker ( 
https://datatracker.ietf.org/doc/draft-daboo-et-al-icalendar-in-xml/ 
).  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
draft-daboo-et-al-icalendar-in-xml-08".

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

Best regards,
-sm

Date: Sat, 16 Apr 2011 05:04:39 -0700
To: Kurt Zeilenga <[email-masked]>
From: SM <[email-masked]>
Cc: [email-masked]
Subject: [apps-review] Request for review: draft-ietf-sidr-rpki-manifests-10

Hi Kurt,

The review of draft-ietf-sidr-rpki-manifests-10 has been assigned to 
you and is due before April 28.

You can find information about the author and WG in the datatracker ( 
https://datatracker.ietf.org/doc/draft-ietf-sidr-rpki-manifests/ 
).  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
draft-ietf-sidr-rpki-manifests-10".

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

Best regards,
-sm

Date: Sat, 16 Apr 2011 05:11:07 -0700
To: [email-masked]
From: SM <[email-masked]>
Subject: [apps-review] Request for review: draft-ietf-dnsop-as112-ops-06

Hello,

I will be reviewing draft-ietf-dnsop-as112-ops-06.  The deadline is 
before April 25.

Best regards,
-sm

Date: Sat, 16 Apr 2011 05:10:14 -0700
To: [email-masked]
From: SM <[email-masked]>
Subject: [apps-review] Request for review: draft-ietf-dnsop-default-local-zones-15

Hello,

I will be reviewing draft-ietf-dnsop-default-local-zones-15.  The 
deadline is before April 25.

Best regards,
-sm

Date: Sat, 16 Apr 2011 05:09:21 -0700
To: [email-masked]
From: SM <[email-masked]>
Subject: [apps-review] Request for review: draft-ietf-dnsop-as112-under-attack-help-help-05

Hello,

I will be reviewing 
draft-ietf-dnsop-as112-under-attack-help-help-05.  The deadline is 
before April 25.

Best regards,
-sm

Date: Sat, 16 Apr 2011 04:58:18 -0700
To: Mark Nottingham <[email-masked]>
From: SM <[email-masked]>
Cc: [email-masked]
Subject: [apps-review] Request for review: draft-ietf-ipfix-structured-data-05

Hi Mark,

The review of draft-ietf-ipfix-structured-data-05 has been assigned 
to you and is due before April 28.

You can find information about the author and WG in the datatracker ( 
https://datatracker.ietf.org/doc/draft-ietf-ipfix-structured-data/ 
).  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
draft-ietf-ipfix-structured-data-05".

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

Best regards,
-sm

Date: Sat, 16 Apr 2011 04:53:13 -0700
To: Tim Bray <[email-masked]>
From: SM <[email-masked]>
Cc: [email-masked]
Subject: [apps-review] Request for review: draft-ietf-xcon-common-data-model-25

Hi Tim,

The review of draft-ietf-xcon-common-data-model-25 has been assigned 
to you and is due before April 28.

You can find information about the author and WG in the datatracker ( 
https://datatracker.ietf.org/doc/draft-ietf-xcon-common-data-model/ 
).  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
draft-ietf-xcon-common-data-model-25".

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

Best regards,
-sm

Date: Sat, 16 Apr 2011 04:50:53 -0700
To: "Henry S. Thompson" <[email-masked]>
From: SM <[email-masked]>
Cc: [email-masked]
Subject: [apps-review] Request for review: draft-ietf-xcon-ccmp-12

Hi Henry,

The review of draft-ietf-xcon-ccmp-12 has been assigned to you and is 
due before April 28.

You can find information about the author and WG in the datatracker ( 
https://datatracker.ietf.org/doc/draft-ietf-xcon-ccmp/ ).  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
draft-ietf-xcon-ccmp-12".

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

Best regards,
-sm

Date: Sat, 16 Apr 2011 04:47:06 -0700
To: Lisa Dusseault <[email-masked]>
From: SM <[email-masked]>
Cc: [email-masked]
Subject: [apps-review] Request for review: draft-ietf-sidr-roa-format-10

The review of draft-ietf-sidr-roa-format-10 has been assigned to you 
and is due before April 28.

You can find information about the author and WG in the datatracker ( 
https://datatracker.ietf.org/doc/draft-ietf-sidr-roa-format/ ).  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
draft-ietf-sidr-roa-format-10".

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

Best regards,
-sm

Date: Sat, 16 Apr 2011 04:43:21 -0700
To: Dave Cridland <[email-masked]>
From: SM <[email-masked]>
Cc: [email-masked]
Subject: [apps-review] Request for review: draft-ietf-grow-geomrt-01

Hi Dave,

The review of draft-ietf-grow-geomrt-01 has been assigned to you and 
is due before April 29.

You can find information about the author and WG in the datatracker ( 
https://datatracker.ietf.org/doc/draft-ietf-grow-geomrt/ ).  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
draft-ietf-grow-geomrt-01".

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

Best regards,
-sm

Date: Sat, 16 Apr 2011 04:38:15 -0700
To: Enrico Marocco <[email-masked]>
From: SM <[email-masked]>
Cc: [email-masked]
Subject: [apps-review] Request for review: draft-ietf-avtext-multicast-acq-rtcp-xr-04

Hi Enrico,

The review of draft-ietf-avtext-multicast-acq-rtcp-xr-04 has been 
assigned to you and is due before April 26.

You can find information about the author and WG in the datatracker ( 
https://datatracker.ietf.org/doc/draft-ietf-avtext-multicast-acq-rtcp-xr/ 
).  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
draft-ietf-avtext-multicast-acq-rtcp-xr-04".

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

Best regards,
-sm

Date: Fri, 15 Apr 2011 19:52:56 -0700
To: Joseph Yee <[email-masked]>
From: SM <[email-masked]>
Cc: Mark Nottingham <[email-masked]>, [email-masked]
Subject: Re: [apps-review] Request for review: draft-ietf-enum-iax-10

Hi Joseph,
At 19:44 15-04-2011, Joseph Yee wrote:
>Sure, assign this to me.  Quick look of the NATPR looks fine.

Thanks, I'll list you as taking over the assignment.  The review is 
due before April 19.

If you are comfortable with DDDS, I may ask you to help Julian out 
with draft-ietf-dime-extended-naptr-06 if he is unfamiliar with the 
subject area.

Best regards,
-sm

From: Joseph Yee <[email-masked]>
Date: Fri, 15 Apr 2011 22:44:05 -0400
To: SM <[email-masked]>
Cc: Mark Nottingham <[email-masked]>, [email-masked]
Subject: Re: [apps-review] Request for review: draft-ietf-enum-iax-10

Hi SM,

Sure, assign this to me.  Quick look of the NATPR looks fine.

And thanks to Peter for XML check.

Joseph

On 2011-04-15, at 9:27 PM, Peter Saint-Andre wrote:

> On 4/15/11 7:04 PM, SM wrote:
>> Hi Mark, Joseph,
>> At 17:15 15-04-2011, Mark Nottingham wrote:
>>> Happy to do it, but I'm not very familiar (at all) with this subject
>>> area.
>> 
>> There are several other reviews which will be assigned within the next
>> few days.  I would have taken this assignment if didn't have other
>> assignments lined up.
>> 
>> Joseph, can I reassign this review to you?  Mark, can you help him with
>> the XML in the IANA Registration Section?
>> 
>> If any other reviewer is familiar with the subject area, please
>> volunteer for this assignment.
> 
> Hi SM, I just took a quick look at this document. The registration XML
> for submission to IANA looks correct to me, and consistent with RFC
> 6117. I haven't double-checked the NAPTR examples, though.
> 
> Peter
> 
> -- 
> Peter Saint-Andre
> https://stpeter.im/
> 
> 
> 

Date: Fri, 15 Apr 2011 19:05:07 -0700
To: Peter Saint-Andre <[email-masked]>
From: SM <[email-masked]>
Cc: Mark Nottingham <[email-masked]>, Joseph Yee <[email-masked]>, [email-masked]
Subject: Re: [apps-review] Request for review: draft-ietf-enum-iax-10

Hi Peter,
At 18:27 15-04-2011, Peter Saint-Andre wrote:
>Hi SM, I just took a quick look at this document. The registration XML
>for submission to IANA looks correct to me, and consistent with RFC
>6117. I haven't double-checked the NAPTR examples, though.

Thanks.  I didn't noticed anything incorrect when I took a quick look 
at the document a few days ago.

Best regards,
-sm 

Date: Fri, 15 Apr 2011 19:27:48 -0600
From: Peter Saint-Andre <[email-masked]>
To: SM <[email-masked]>
OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc
Cc: Mark Nottingham <[email-masked]>, Joseph Yee <[email-masked]>, [email-masked]
Subject: Re: [apps-review] Request for review: draft-ietf-enum-iax-10

This is a cryptographically signed message in MIME format.

--------------ms080604060707040100090107
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On 4/15/11 7:04 PM, SM wrote:
> Hi Mark, Joseph,
> At 17:15 15-04-2011, Mark Nottingham wrote:
>> Happy to do it, but I'm not very familiar (at all) with this subject
>> area.
>=20
> There are several other reviews which will be assigned within the next
> few days.  I would have taken this assignment if didn't have other
> assignments lined up.
>=20
> Joseph, can I reassign this review to you?  Mark, can you help him with=

> the XML in the IANA Registration Section?
>=20
> If any other reviewer is familiar with the subject area, please
> volunteer for this assignment.

Hi SM, I just took a quick look at this document. The registration XML
for submission to IANA looks correct to me, and consistent with RFC
6117. I haven't double-checked the NAPTR examples, though.

Peter

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

--------------ms080604060707040100090107
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

AAAA
--------------ms080604060707040100090107--

Date: Fri, 15 Apr 2011 18:04:38 -0700
To: Mark Nottingham <[email-masked]>, Joseph Yee <[email-masked]>
From: SM <[email-masked]>
Cc: [email-masked]
Subject: Re: [apps-review] Request for review: draft-ietf-enum-iax-10

Hi Mark, Joseph,
At 17:15 15-04-2011, Mark Nottingham wrote:
>Happy to do it, but I'm not very familiar (at all) with this subject area.

There are several other reviews which will be assigned within the 
next few days.  I would have taken this assignment if didn't have 
other assignments lined up.

Joseph, can I reassign this review to you?  Mark, can you help him 
with the XML in the IANA Registration Section?

If any other reviewer is familiar with the subject area, please 
volunteer for this assignment.

Best regards,
-sm 

From: Mark Nottingham <[email-masked]>
Date: Sat, 16 Apr 2011 10:15:54 +1000
To: SM <[email-masked]>
Cc: [email-masked]
Subject: Re: [apps-review] Request for review: draft-ietf-enum-iax-10

Happy to do it, but I'm not very familiar (at all) with this subject =
area.

Cheers,

On 16/04/2011, at 9:11 AM, SM wrote:

> Hi Mark,
>=20
> The review of draft-ietf-enum-iax-10 has been assigned to you and is =
due before April 19.
>=20
> You can find information about the author and WG in the datatracker ( =
https://datatracker.ietf.org/doc/draft-ietf-enum-iax/ ).  Some previous =
reviews from the Apps-review Team are accessible at =
http://www.apps.ietf.org/content/apps-review-template
>=20
> The review should be sent to apps-discuss, the authors, the IESG, the =
WG Chairs and document shepherd, if applicable.
>=20
> The subject of the email when submitting the review should be =
"apps-team review of
> draft-ietf-enum-iax-10".
>=20
> If I don't receive an acknowledgement from you within two days, I'll =
send you a reminder before reassigning the review.
>=20
> Best regards,
> -sm
>=20

--
Mark Nottingham   http://www.mnot.net/

Date: Fri, 15 Apr 2011 16:14:47 -0700
To: Julian Reschke <[email-masked]>
From: SM <[email-masked]>
Cc: [email-masked]
Subject: [apps-review] Request for review: draft-ietf-dime-extended-naptr-06

Hi Julian,

The review of draft-ietf-dime-extended-naptr-06 has been assigned to 
you and is due before April 20.

You can find information about the author and WG in the datatracker ( 
https://datatracker.ietf.org/doc/draft-ietf-dime-extended-naptr/ 
).  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
draft-ietf-dime-extended-naptr-06".

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: Fri, 15 Apr 2011 16:11:19 -0700
To: Mark Nottingham <[email-masked]>
From: SM <[email-masked]>
Cc: [email-masked]
Subject: [apps-review] Request for review: draft-ietf-enum-iax-10

Hi Mark,

The review of draft-ietf-enum-iax-10 has been assigned to you and is 
due before April 19.

You can find information about the author and WG in the datatracker ( 
https://datatracker.ietf.org/doc/draft-ietf-enum-iax/ ).  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
draft-ietf-enum-iax-10".

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, 05 Apr 2011 15:24:55 -0600
From: Peter Saint-Andre <[email-masked]>
To: Barry Leiba <[email-masked]>
OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc
Cc: [email-masked]
Subject: Re: [apps-review] Request for review:	draft-ietf-vcarddav-vcardrev-16

This is a cryptographically signed message in MIME format.

--------------ms090108020709030001050404
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On 4/3/11 12:44 PM, Barry Leiba wrote:
>> Barry, would you be able to review draft-ietf-vcarddav-vcardrev-16 by =
April
>> 18?
>=20
> Yes.

Thanks, Barry.

We'll also want to review vcardxml (to make sure that it is in sync with
the core spec) and ical-in-xml (to make sure that it is in sync with
vcardxml regarding XML issues), but those can be done by other people.

Peter

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

--------------ms090108020709030001050404
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

AAAA
--------------ms090108020709030001050404--

Sender: [email-masked]
Date: Sun, 3 Apr 2011 14:44:21 -0400
From: Barry Leiba <[email-masked]>
To: SM <[email-masked]>
Cc: [email-masked]
Subject: Re: [apps-review] Request for review: draft-ietf-vcarddav-vcardrev-16

> Barry, would you be able to review draft-ietf-vcarddav-vcardrev-16 by April
> 18?

Yes.

b

Date: Sun, 03 Apr 2011 06:17:23 -0700
To: Barry Leiba <[email-masked]>, Eliot Lear <[email-masked]>
From: SM <[email-masked]>
Cc: [email-masked]
Subject: Re: [apps-review] Request for review: draft-ietf-vcarddav-vcardrev-16

Hi Barry,
At 00:01 03-04-2011, Eliot Lear wrote:
>This is an important draft.  Unfortunately I cannot devote sufficient
>time to it this month.  May I request that someone else be assigned?

Thanks for notifying me.

Barry, would you be able to review draft-ietf-vcarddav-vcardrev-16 by April 18?

Best regards,
-sm 

Date: Sun, 03 Apr 2011 09:01:47 +0200
From: Eliot Lear <[email-masked]>
To: SM <[email-masked]>
Cc: [email-masked]
Subject: Re: [apps-review] Request for review: draft-ietf-vcarddav-vcardrev-16

SM,

This is an important draft.  Unfortunately I cannot devote sufficient
time to it this month.  May I request that someone else be assigned?

Thanks,

Eliot
> Hi Eliot,
>
> Pete requested a review of draft-ietf-vcarddav-vcardrev-16.  The
> review has been assigned to you and is due by April 18.  If you need
> more time, please contact me.
>
> You can find information about the author and WG in the datatracker (
> https://datatracker.ietf.org/doc/draft-ietf-vcarddav-vcardrev/ ). 
> 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
> draft-ietf-vcarddav-vcardrev-16".
>
> Best regards,
> -sm
>
>

Date: Sat, 02 Apr 2011 21:57:19 -0700
To: Eliot Lear <[email-masked]>
From: SM <[email-masked]>
Cc: [email-masked]
Subject: [apps-review] Request for review: draft-ietf-vcarddav-vcardrev-16

Hi Eliot,

Pete requested a review of draft-ietf-vcarddav-vcardrev-16.  The 
review has been assigned to you and is due by April 18.  If you need 
more time, please contact me.

You can find information about the author and WG in the datatracker ( 
https://datatracker.ietf.org/doc/draft-ietf-vcarddav-vcardrev/ 
).  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
draft-ietf-vcarddav-vcardrev-16".

Best regards,
-sm