Subject: [apps-review] Q on applicability of http://www.ietf.org/id/draft-montemurro-gsma-imei-urn-05.txt
From: Scott Brim <[email-masked]>
To: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Date: Wed, 29 Sep 2010 11:35:24 -0400
List-Id: Apps Area Review List <apps-review.ietf.org>

Pardon me but I don't understand the use case for this:

   GSM, UMTS and LTE mobile devices will be interoperating with Internet
   devices for a variety of voice and data services.  To do this, they
   need to make use of Internet protocols that will operate end to end
   between devices in GSM/UMTS/LTE networks and those in the general
   internet.  Many of these protocols require the use of URN's as
   identifiers.  Within the GSM/UMTS/LTE networks, mobile devices are
   identified by their IMEI and IMEISV.  Internet users will need to be
   able to receive and include the GSMA URN in various Internet protocol
   elements to facilitate communication between pure internet based
   devices and GSM/UMTS/LTE mobile devices.  Thus the existence and
   syntax of these namespaces needs to be available to the general
   internet community and the namespace needs to be reserved with IANA
   in order to guarantee uniqueness and prevent potential namespace
   conflicts both within the internet and within GSM/UMTS/LTE networks.

First, this feels like a layering mixup.  When would -- or should -- a
communicating peer outside a mobile network need to know the IMEI or
IMEISV of a device inside a mobile network?  An IMEI is used for initial
identification on a mobile network or for SIM-less emergency calls.
Under what conditions would an Internet-based peer have an IMEI in hand
and want to use it in a gsma: URN?  If as you say an "Internet device"
is "interoperating" with a mobile device, it will do so using IP-based
protocols and will (should) never learn the mobile device's IMEI.  I can
see cases where an outsourced management entity might want to speak to a
mobile network's administration regarding records for a particular IMEI,
but it would do so in a very secure way, not using this particular URN.

If there is an assumption that we are going to start passing around
IMEIs as general identifiers, then I'm concerned that you are
engineering a world in which one must reveal permanent identifiers in
order to communicate.

Please enlighten me as to the intent.  Right now it feels to me like it
enables us to do the wrong thing with IMEIs.

Thanks ... Scott

Date: Mon, 27 Sep 2010 12:29:48 -0700
To: Julian Reschke <[email-masked]>
From: SM <[email-masked]>
Cc: [email-masked]
Subject: Re: [apps-review] Fwd: APP Area Review of draft-ietf-ecrit-lost-sync-09

Hi Julian,
At 06:33 27-09-10, Julian Reschke wrote:
>Subject: APP Area Review of draft-ietf-ecrit-lost-sync-09
>Date: Mon, 27 Sep 2010 15:32:45 +0200

[snip]

>I have been selected as the Applications Area Review Team reviewer for
>this draft (for background on apps-review, please see

Many thanks for doing the review.

Best regards,
-sm 

Date: Sun, 26 Sep 2010 03:39:06 -0700
To: [email-masked]
From: SM <[email-masked]>
Subject: [apps-review] XML expertise

Hello,

We have had several requests for XML reviews during the last 
months.  It has been difficult to find reviewers with XML 
expertise.  I would be grateful if you can recommend reviewers with 
XML expertise who are willing to join the Applications Area Review Team.

Mark Baker was not listed as member of the Applications Area Review 
Team on 
http://www.apps.ietf.org/content/applications-area-review-team  I 
apologize for the mistake.

Best regards,
-sm

Date: Sun, 26 Sep 2010 02:51:36 -0700
To: [email-masked]
From: SM <[email-masked]>
Subject: [apps-review] Review of draft-arkko-townsley-coexistence-04

Hello,

I will be taking over the assignment to review 
draft-arkko-townsley-coexistence-04 before October 12.

Regards,
-sm

Date: Sun, 26 Sep 2010 02:45:57 -0700
To: Barry Leiba <[email-masked]>
From: SM <[email-masked]>
Cc: [email-masked]
Subject: [apps-review] Review of draft-ietf-csi-hash-threat-10

Hi Barry,

Peter requested a review of draft-ietf-csi-hash-threat-10 before 
October 12, 2010.  The request is being assigned to you.  You can 
find information about  the author and WG in the datatracker ( 
https://datatracker.ietf.org/doc/draft-ietf-csi-hash-threat ).  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 author, WG Chair and 
document shepherd, if applicable, and the IESG.  The subject of the 
email when submitting the review should be "apps-team review of 
draft-ietf-csi-hash-threat-10".

Best regards,
-sm

Date: Sun, 26 Sep 2010 02:37:36 -0700
To: Xiaodong Lee <[email-masked]>
From: SM <[email-masked]>
Cc: [email-masked]
Subject: [apps-review] Review of draft-cridland-acap-vendor-registry-01

Hi Xiaodong,

Pete requested a review of draft-cridland-acap-vendor-registry-01 
before October 12, 2010.  The request is being assigned to you.  You 
can find information about the author and WG in the datatracker ( 
https://datatracker.ietf.org/doc/draft-cridland-acap-vendor-registry 
).  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 author, WG Chair and 
document shepherd, if applicable, and the IESG.  The subject of the 
email when submitting the review should be "apps-team review of 
draft-cridland-acap-vendor-registry-01".

Best regards,
-sm

Date: Sun, 26 Sep 2010 02:16:39 -0700
To: Joe Hildebrand <[email-masked]>
From: SM <[email-masked]>
Cc: [email-masked]
Subject: [apps-review] Review of draft-ietf-dime-capablities-update-05

Hi Joe,

Peter requested a review of draft-ietf-dime-capablities-update-05 
before October 12, 2010.  The request is being assigned to you.  You 
can find information about the author and WG in the datatracker ( 
https://datatracker.ietf.org/doc/draft-ietf-dime-capablities-update 
).  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 author, WG Chair and 
document shepherd, if applicable, and the IESG.  The subject of the 
email when submitting the review should be "apps-team review of 
draft-ietf-dime-capablities-update-05".

Best regards,
-sm

Date: Thu, 23 Sep 2010 14:46:26 -0700
To: Carsten Bormann <[email-masked]>
From: SM <[email-masked]>
Cc: [email-masked]
Subject: Re: [apps-review] [apps-discuss] apps-team review of draft-ietf-netmod-arch

Hi Carsten,
At 13:58 23-09-10, Carsten Bormann wrote:
>Hmm, I sent it there.
>Let me check...  Yes, I do receive apps-discuss mail.  So it can't 
>be a non-member reject.

If it was a non-member reject, the message would also end up in the 
moderator queue.

>Fluke?  Hmm.  I just resent it.  Let's see whether that copy arrives.

I'll wait to see whether the message turns up in the archive.  I put 
in a reference to that message when I update the list of reviews in 
the tracker ( http://www.apps.ietf.org/content/apps-review-tracker ).

>This is an order of magnitude more work.

That may explain why we haven't been able to get a review even though 
that draft has been assigned twice.

>This is a very interesting draft.  But it is also massive, bridging 
>no less than four schema technologies.
>I'm not sure I can do this review in a timely fashion.

I'll discuss about the alternatives off-list.

Best regards,
-sm 

To: Yves Lafon <[email-masked]>
Date: Thu, 23 Sep 2010 14:12:49 -0400
From: Eric Rosen <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: [apps-review] Review of draft-ietf-l3vpn-mvpn-spmsi-joins-01
Reply-To: [email-masked]

Yves, thanks for your comments.

> Is this going to obsolete the Type 1 S-PMSI Join message defined in
> draft-ietf-l3vpn-2547bis-mcast-10.txt (using IPv4-mapped IPv6 addresses)?

No, that is not the intention.  If the VPN customer is using IPv4, then the
type 1 S-PMSI Join will still be used.  The type 4 is used only if the VPN
customer is using IPv6.

> In the reference sections, links to drafts should be labelled '(Work in
> progress)'

Well, in this particular case, the referenced draft is already on the RFC
Editor's publication queue; also the reference is normative.  So labeling it
as "work in progress" would not really be appropriate.  The RFC Editor
will bring the reference up to date when the drafts are published.

Date: Thu, 23 Sep 2010 12:15:28 -0400 (EDT)
From: Yves Lafon <[email-masked]>
To: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: [apps-review] Review of draft-ietf-l3vpn-mvpn-spmsi-joins-01

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

Document: draft-ietf-l3vpn-mvpn-spmsi-joins-01
Reviewer: Yves Lafon
Review Date: 22 September 2010

Review Summary:
This draft seems ready to advance, depending on=20
draft-ietf-l3vpn-2547bis-mcast-10

Document Summary:
This document define a new "S-PMSI Join" message and PIM to extends MVPN=20
to IPv6 flows.
There are no apps-related issues in this document.
The security section is accuratey referring to=20
draft-ietf-l3vpn-2547bis-mcast-10

Major issues:
   none

Minor issues:
In the reference sections, links to drafts should be labelled
'(Work in progress)'

And one question: Is this going to obsolete the Type 1 S-PMSI Join message=
=20
defined in draft-ietf-l3vpn-2547bis-mcast-10.txt (using IPv4-mapped IPv6=20
addresses) ?

Cheers,

--=20
Baroula que barouleras, au ti=E9u toujou t'entourneras.

         ~~Yves

Date: Thu, 23 Sep 2010 08:46:40 -0700
To: Carsten Bormann <[email-masked]>
From: SM <[email-masked]>
Cc: [email-masked]
Subject: Re: [apps-review] [apps-discuss] apps-team review of draft-ietf-netmod-arch

Hi Carsten,
At 05:39 23-09-10, Phil Shafer wrote:
>Carsten Bormann writes:
> >I have been selected as the Applications Area Review Team reviewer

I cannot find the review in the Apps-discuss mailing list 
archives.  Could you please re-post the review to that mailing list?

>DSDL includes Relax NG, and Relax NG has far better name recognition,
>so it was added in parens.  I can add text to fully describe this
>relationship.

draft-ietf-netmod-dsdl-map is pending Apps review.  Can I convince 
you to review that draft? :-)

Best regards,
-sm 

Date: Thu, 23 Sep 2010 00:28:59 +0200 (CEST)
From: Andrew Yourtchenko <[email-masked]>
To: Fernando Gont <[email-masked]>
Cc: [email-masked], Apps Area Review List <[email-masked]>, The IESG <[email-masked]>, Security Area Directorate <[email-masked]>, Dave Cridland <[email-masked]>
Subject: Re: [apps-review] SecDir/Apps Review of draft-ietf-tcpm-urgent-data-06

Hi David,

sorry for the delay with the reply - I was off the grid
for a couple of weeks due to vacation.

On Thu, 16 Sep 2010, Fernando Gont wrote:

[snip]

>> The Cisco-PIX reference does not describe the TCP Urgent behaviour
>> except by implication (it mentions adding rules to allow its use for
>> TELNET and FTP-PI, but that's it). I have a personal distaste for
>> product placement in RFCs, and would prefer that this reference pointed
>> at least at a Cisco paper describing default behaviour, etc.
>>

I comment on this below at [*]

>> As an aside, the Cisco instructions actually show the user how to enable
>> urgent data on FTP-DTP, rather than FTP-PI, which is incorrect.

Could you unicast me the URL where you saw it, so I can work to get it fixed ?

The ones in the command reference for the ASA talk about tcp/513, which is 
rlogin, e.g.:

http://www.cisco.com/en/US/docs/security/asa/asa80/command/reference/uz.html#wp1591004

>
> I leave this one for Andrew to answer ;-)
>
> I'd just note that the reason for which Cisco Pix is referenced is
> probably because it's a widely deployed device that scrubs urgent
> indications. (i.e., "this thing is widely deployed").
>

Exactly.

[*] - given the contents of the command reference above - would it correspond to 
what you had in mind if we give e.g. the link above to one of the command 
references ?

>
>> Specific Recommendations:
>>
>> - An informative reference to FTP and TELNET, noting how and why the URG
>> pointer is used, would make it more obvious what is lost here.
>
> Would the re-written text I indicated above do, or do you think we
> should get into the specifics of what the urgent mechanism is used for
> in FTP and telnet?
>
>
>
>> - A more detailed description of SeolMa, and its implications, would be
>> useful, and I think required in the Security Considerations section.
>
> Please let me know if the change indicated above would do.
>
>
>> - I feel that further consideration of the proposed solution to SeolMa
>> is warranted.
>
> You mean what we propose to fix this NIDS evasion technique?

SeolMa was in fact one of the initial triggers of this work, though we deemed 
the NIDS problem as not something practically solvable in a clean way.

I'll include the logic below:

First the "classic" NIDS:

The setup is as follows:

Alice --+-- Eva
         |
        Nick

Eva is trying to exploit Alice using the SeolMa technique.
Regardless of the setup, Nick can not do a lot anyway to help - maybe send a 
reset based on some heuristic, however the damage is possibly already done, 
might depend on the timing.

So we consider a more interesting case of an "inline" setup:

Alice -- Nick -- Eva

Here, Nick can have the power to reliably do something. But he 
needs to consider the following degrees of freedom that Alice has:

* /proc/sys/net/ipv4/tcp_stdurg setting.

This alters the behaviour box-wide, and Nick would need to know the value of 
this setting (manual configuration), to understand in which of the two ways
to interpret the data.

* The timing also plays a role, so Nick would need to 
somehow normalize the timing of the packets before passing them on to Alice. 
This can either impact the TCP connection itself (if done with bigger safety 
margins), or be again unreliable. Or the packets need to be sanitized.

* Meantime, Alice might have learned about the SO_OOBINLINE and added that to 
the code of the next version of the application - which gives another point of 
manual configuration for Nick.

Based on that, there are some approaches to tackling this:

* Nick manually configures his behavior to match the Alice's and then does the 
analysis based on that, trying to guess what Alice's stack would do - and then 
pass the "sanitized" packets to Alice.

==> while technically this looks sound, I think expecting the end user en masse
to know about the details about SO_OOBINLINE/tcp_stdurg is impractical.
Even if the "security" folks might know it, in a lot of organizations they are 
different from "application" folks - the latter not possessing the 
low-level transports knowledge. Side effect of this is the increase of the 
complexity of the task that Nick would do, therefore increasing the chances of 
it not emulating the Alice's behaviour correctly.

* Nick can evade the evasion by clearing the URG flag - breaking
the assumptions of Eve about the processing of the data by Alice.

==> This requires zero configuration, creates loud noise in the logs of Alice 
due to incorrect input, but breaks the apps that rely on
URG mechanism during the legitimate operation.

* Nick can be aggressive on those streams that he knows would not use urgent 
mechanism (e.g. HTTP), and try to handle the ones that may use it, in a more 
graceful manner.

==> This looks like a possibly ideal scenario, however, from the security point 
of view for the applications that use the urgent mechanism, it would need to be 
treated as the first one - i.e. require explicit manual configuration.

So the approach with simply clearing the URG looks like the simplest of all from 
several viewpoints (reliability, and maintenance overhead).

Hopefully this gives more details, would be very useful to know your 
opinion on the above.

Thank you very much!

kind regards,
andrew

>
> Thanks!
>
> Kind regards,
> -- 
> Fernando Gont
> e-mail: [email-masked] || [email-masked]
> PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1
>
>
>
>

Date: Wed, 22 Sep 2010 21:26:45 +0200 (CEST)
From: Claudio Allocchio <[email-masked]>
To: Ted Hardie <[email-masked]>
Cc: [email-masked]
Subject: Re: [apps-review] Applications Area Review Team status

> I actually wondered whether I should send a "caught" message when
> the review request to me came in. I understand your concern about delay,
> but I think it would be a good idea (on a best effort basis, as for
> your reminders
> below) if folks agreeing to do a review did say something like "Will
> do".  I will
> do that in future, and I'd suggest others do so as well.

well, my guess is that any of us shall send a "got it!" when a request is 
assigned, it's also a matter of politeness to the review team coordinator 
:-)

Yes, let make it "good practice".

best regards to all of you.

------------------------------------------------------------------------------
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: Wed, 22 Sep 2010 12:09:32 -0700
To: Ted Hardie <[email-masked]>
From: SM <[email-masked]>
Cc: [email-masked]
Subject: Re: [apps-review] Applications Area Review Team status

Hi Ted,
At 11:07 22-09-10, Ted Hardie wrote:
>I actually wondered whether I should send a "caught" message when
>the review request to me came in. I understand your concern about delay,
>but I think it would be a good idea (on a best effort basis, as for
>your reminders
>below) if folks agreeing to do a review did say something like "Will
>do".  I will
>do that in future, and I'd suggest others do so as well.

Thanks for the feedback.  It's easier for me if you send a "caught" 
message as I would be less concerned about the assignment then.  As I 
haven't had regular email exchanges with all team members, I am not 
familiar with everyone's style of communication.  I'll expect a reply 
within two days before considering a reassignment.  as far as 
possible, I'll send reminders a few days before the assignment is due.

I am open to suggestions on how to get the work done.  If I am doing 
anything wrong or anyone has an idea, feel free to drop me an email 
or post to the mailing list.

Best regards,
-sm

P.S. Thanks to Carsten. 

Date: Wed, 22 Sep 2010 11:07:48 -0700
From: Ted Hardie <[email-masked]>
To: SM <[email-masked]>
Cc: [email-masked]
Subject: Re: [apps-review] Applications Area Review Team status

On Wed, Sep 22, 2010 at 10:59 AM, SM <[email-masked]> wrote:
> Dear Applications Area Review Team,
>

> It has been suggested to me that the reviewer should confirm that he or s=
he
> is taking the assignment. =A0I don't think that it would be workable in
> practice. =A0The deadline for an assignment can be less than a week and t=
he
> next reviewer would have less time for the assignment if I have to wait a
> few days for your reply. =A0If the team thinks that it would be good to w=
ait
> for the confirmation, I'll follow that practice.
>

I actually wondered whether I should send a "caught" message when
the review request to me came in. I understand your concern about delay,
but I think it would be a good idea (on a best effort basis, as for
your reminders
below) if folks agreeing to do a review did say something like "Will
do".  I will
do that in future, and I'd suggest others do so as well.

regards,

Ted

> My little experience of sending reminders points to it not always produci=
ng
> the desired results as people might be too busy to respond to them. =A0I =
may
> send out reminders a few days before the review is due on a best effort
> basis.
>
> You are probably aware that WG Chairs outside the Application Area have
> asked the team for reviews of some of their drafts. =A0The team ends up
> looking bad if we cannot deliver on that in a timely manner. =A0Our frien=
dly
> Area Directors have asked for a review of a draft since May 10th. =A0The
> review is still pending.
>
> Regards,
> S. Moonesamy
>
> 1. http://www.apps.ietf.org/content/apps-review-tracker
> 2. http://www.ietf.org/mail-archive/web/apps-discuss/current/msg01716.htm=
l
> 3. http://www.ietf.org/mail-archive/web/apps-review/current/msg00263.html
>
> _______________________________________________
> apps-review mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/apps-review
>

Date: Wed, 22 Sep 2010 10:59:11 -0700
To: [email-masked]
From: SM <[email-masked]>
Subject: [apps-review] Applications Area Review Team status

Dear Applications Area Review Team,

I'll start this message by saying that Applications Area Review Team 
would not exist without you volunteering to put in the time and 
effort to get the work done.  The team has been very active this 
month.  We got seven reviews done [1].  Dave Cridland deserves a 
special note for doing two reviews out of that.  There are still some 
reviews that are pending.  I'll list them in the monthly report to 
the Apps-discuss mailing list [2].

The objective of the Applications Area Review Team is to provide 
reviews.  I read that as meaning that, you have implicitly accepted 
to do the reviews that are assigned to you.  On  May 17th, I posted a 
message about how the team could get the work done [3].  I mentioned 
that you could notify me in advance if you are going on vacation or 
you cannot take up assignments.  If an expert review is needed and 
the assignment is not within your field of expertise, please let me know.

It has been suggested to me that the reviewer should confirm that he 
or she is taking the assignment.  I don't think that it would be 
workable in practice.  The deadline for an assignment can be less 
than a week and the next reviewer would have less time for the 
assignment if I have to wait a few days for your reply.  If the team 
thinks that it would be good to wait for the confirmation, I'll 
follow that practice.

My little experience of sending reminders points to it not always 
producing the desired results as people might be too busy to respond 
to them.  I may send out reminders a few days before the review is 
due on a best effort basis.

You are probably aware that WG Chairs outside the Application Area 
have asked the team for reviews of some of their drafts.  The team 
ends up looking bad if we cannot deliver on that in a timely 
manner.  Our friendly Area Directors have asked for a review of a 
draft since May 10th.  The review is still pending.

Regards,
S. Moonesamy

1. http://www.apps.ietf.org/content/apps-review-tracker
2. http://www.ietf.org/mail-archive/web/apps-discuss/current/msg01716.html
3. http://www.ietf.org/mail-archive/web/apps-review/current/msg00263.html

Date: Wed, 22 Sep 2010 09:29:33 -0700
To: Eric Johnson <[email-masked]>
From: S Moonesamy <[email-masked]>
Cc: [email-masked]
Subject: Re: [apps-review] New posting of the "jms" URI scheme

Hi Eric,
At 09:58 20-09-10, Eric Johnson wrote:
>At the suggestion of Alexey Melnikov, I'm submitting this draft to 
>this list, as well as the uri-review mailing list.

The review of draft-merrick-jms-uri-09 has been assigned to Mark Nottingham.

Regards,
S. Moonesamy
On behalf of the Applications Area Review Team
http://www.apps.ietf.org/content/applications-area-review-team 

From: "Polk, William T." <[email-masked]>
To: Fernando Gont <[email-masked]>, Dave Cridland <[email-masked]>
Date: Wed, 22 Sep 2010 09:23:03 -0400
Accept-Language: en-US
acceptlanguage: en-US
Cc: "[email-masked]" <[email-masked]>, Apps Area Review List <[email-masked]>, The IESG <[email-masked]>, Security Area Directorate <[email-masked]>
Subject: Re: [apps-review] SecDir/Apps Review of draft-ietf-tcpm-urgent-data-06

Hi Fernando,

My comments inline, text pruned to those issues I am responding to...

On 9/16/10 3:40 AM, "Fernando Gont" <[email-masked]> wrote:

=20
>> The TCP urgent mechanism, as implemented, means that a single octet is
>> lost when the receiver handles the last "Urgent" data section. Thus
>> particularly when multiple urgent data segments are "in flight", it
>> becomes difficult to guess which octets will be lost by the receiver.
>> The SeolMa attack effectively uses these lost octets to pad strings used
>> in TCP based application protocols, thus defeating na=EFve NIDS pattern
>> matching.
>>=20
>> There is no discussion in the draft about SeolMa, indeed there isn't
>> even a mention of it in the Security Considerations.
>=20
> The security considerations does mention the problem of NIDS-evasion,
> although it only focuses on the semantics of the UP (but does not
> consider the OOB vs. in-band thing). Would re-writing the SecCons as
> follows address this point?:
>=20
> ---- cut here ----
> Multiple factors can affect the data flow that is actually delivered to
> an application when the TCP urgent mechanism is employed; namely, the
> two possible interpretations of the semantics of the Urgent Pointer in
> current implementations (e.g., depending on the value of the tcp_stdurg
> sysctl), the possible implementation of the urgent mechanism as an
> Out-Of-Band (OOB) facility (vs. in-band as intenteded by the IETF
> specifications), and middle-boxes (such as packet scrubbers) or the
> end-systems themselves that could cause the "urgent data" to be
> processed "in band". This might make it difficult for a Network
> Intrusion Detection System (NIDS) to track the application-layer data
> transferred to the destination system, and thus lead to false negatives
> or false positives in the NIDS [CPNI-TCP] [phrack].
> ---- cut here ----
>=20
I think this is a helpful change.

>=20
>> It's not clear to
>> me if the recommendation to use SO_OOBINLINE would have an effect here -
>> my gut feeling is that it would defeat SeolMa by making these "lost"
>> octets part of the normal data flow again.
>=20
> This wouldn't help for the challenge that NIDS face. This just helps in
> terms of interoperability: i.e., applications should still work if those
> "urgent data" are delivered in-band (whether because of setting
> SO_OOBINLINE or because a packet scrubber cleared the URG bit).
>=20
>=20
>=20
>> Cisco's solution relies on simply forcing urgent data to be non-urgent,
>> which will have knock-on effects on TELNET and FTP by default. It's not
>> clear to me from this document (including reading the references)
>=20
> How about if I replace this sentence of the SecCons:
>=20
> ---- cut here ----
> However, this
>    might cause interoperability problems or undesired behavior in the
>    applications running on top of TCP.
> ---- cut here ----
>=20
> with this one:
>=20
> ---- cut here ----
> However, this might cause interoperability problems or undesired
> behavior in those applications that rely on the TCP urgent mechanism,
> such as Telner [telnet] and FTP [ftp]
> ---- cut here ----
>=20
> ?
I think this is also a helpful change.
>=20
>=20
>> Specific Recommendations:
>>=20
>> - An informative reference to FTP and TELNET, noting how and why the URG
>> pointer is used, would make it more obvious what is lost here.
>=20
> Would the re-written text I indicated above do, or do you think we
> should get into the specifics of what the urgent mechanism is used for
> in FTP and telnet?
>=20
>=20
It might be worth highlight FTP and TELNET in Section 5, since these are
evidently common applications that use the urgent data feature.
>=20
>> - A more detailed description of SeolMa, and its implications, would be
>> useful, and I think required in the Security Considerations section.
>=20
> Please let me know if the change indicated above would do.
>=20
>=20
>> - I feel that further consideration of the proposed solution to SeolMa
>> is warranted.
>=20
> You mean what we propose to fix this NIDS evasion technique?
>=20

At a minimum, I think the implications of this document and any impact on
SeolMa are needed to complete the security considerations section.

> Thanks!
>=20
> Kind regards,
> --
> Fernando Gont
> e-mail: [email-masked] || [email-masked]
> PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1
>=20
>=20
>=20
>=20
>=20

Thanks,

Tim

Date: Mon, 20 Sep 2010 09:58:23 -0700
From: Eric Johnson <[email-masked]>
To: [email-masked]
Subject: [apps-review] New posting of the "jms" URI scheme

At the suggestion of Alexey Melnikov, I'm submitting this draft to this 
list, as well as the uri-review mailing list.

Please send along your comments.

http://tools.ietf.org/html/draft-merrick-jms-uri-09

This version addresses a bunch of concerns raised privately in email by 
members of the IETF, mostly around the question of how to compare two 
"jms" URIs, as well as removing non-normative uses of RFC 2119 language.

-Eric.

Sender: Fernando Gont <[email-masked]>
Date: Thu, 16 Sep 2010 04:40:30 -0300
From: Fernando Gont <[email-masked]>
To: Dave Cridland <[email-masked]>
OpenPGP: id=D076FFF1
Cc: [email-masked], Security Area Directorate <[email-masked]>, The IESG <[email-masked]>, Apps Area Review List <[email-masked]>
Subject: Re: [apps-review] SecDir/Apps Review of draft-ietf-tcpm-urgent-data-06

Hi, David,

Thanks so much for your feedback!

Please find my comments inline....

> Simply dropping TCP Urgent data facilities removes an aspect of TCP
> which - whilst not commonly used in most modern protocols - is
> nevertheless still used for useful gain in FTP and TELNET.

Actually, support for urgent data is not removed. We simply discourage
its use.

> The TCP urgent mechanism, as implemented, means that a single octet is
> lost when the receiver handles the last "Urgent" data section. Thus
> particularly when multiple urgent data segments are "in flight", it
> becomes difficult to guess which octets will be lost by the receiver.
> The SeolMa attack effectively uses these lost octets to pad strings used
> in TCP based application protocols, thus defeating naïve NIDS pattern
> matching.
>
> There is no discussion in the draft about SeolMa, indeed there isn't
> even a mention of it in the Security Considerations. 

The security considerations does mention the problem of NIDS-evasion,
although it only focuses on the semantics of the UP (but does not
consider the OOB vs. in-band thing). Would re-writing the SecCons as
follows address this point?:

---- cut here ----
Multiple factors can affect the data flow that is actually delivered to
an application when the TCP urgent mechanism is employed; namely, the
two possible interpretations of the semantics of the Urgent Pointer in
current implementations (e.g., depending on the value of the tcp_stdurg
sysctl), the possible implementation of the urgent mechanism as an
Out-Of-Band (OOB) facility (vs. in-band as intenteded by the IETF
specifications), and middle-boxes (such as packet scrubbers) or the
end-systems themselves that could cause the "urgent data" to be
processed "in band". This might make it difficult for a Network
Intrusion Detection System (NIDS) to track the application-layer data
transferred to the destination system, and thus lead to false negatives
or false positives in the NIDS [CPNI-TCP] [phrack].
---- cut here ----

> It's not clear to
> me if the recommendation to use SO_OOBINLINE would have an effect here -
> my gut feeling is that it would defeat SeolMa by making these "lost"
> octets part of the normal data flow again.

This wouldn't help for the challenge that NIDS face. This just helps in
terms of interoperability: i.e., applications should still work if those
"urgent data" are delivered in-band (whether because of setting
SO_OOBINLINE or because a packet scrubber cleared the URG bit).

> Cisco's solution relies on simply forcing urgent data to be non-urgent,
> which will have knock-on effects on TELNET and FTP by default. It's not
> clear to me from this document (including reading the references)

How about if I replace this sentence of the SecCons:

---- cut here ----
However, this
   might cause interoperability problems or undesired behavior in the
   applications running on top of TCP.
---- cut here ----

with this one:

---- cut here ----
However, this might cause interoperability problems or undesired
behavior in those applications that rely on the TCP urgent mechanism,
such as Telner [telnet] and FTP [ftp]
---- cut here ----

?

> By instituting a blanket ban, in effect, for TCP Urgent data, this
> effectively deprecates the entire mechanism. This may prove to be the
> only solution, however my general feeling is that this may not be the case.

Not that I like it... but in practice, it probably is. As you correctly
mentioned before, when multiple segments are in flight, it becomes
virtually impossible for a NIDS to be able to do its job.

> Niggle:
> 
> The Cisco-PIX reference does not describe the TCP Urgent behaviour
> except by implication (it mentions adding rules to allow its use for
> TELNET and FTP-PI, but that's it). I have a personal distaste for
> product placement in RFCs, and would prefer that this reference pointed
> at least at a Cisco paper describing default behaviour, etc.
> 
> As an aside, the Cisco instructions actually show the user how to enable
> urgent data on FTP-DTP, rather than FTP-PI, which is incorrect.

I leave this one for Andrew to answer ;-)

I'd just note that the reason for which Cisco Pix is referenced is
probably because it's a widely deployed device that scrubs urgent
indications. (i.e., "this thing is widely deployed").

> Specific Recommendations:
> 
> - An informative reference to FTP and TELNET, noting how and why the URG
> pointer is used, would make it more obvious what is lost here.

Would the re-written text I indicated above do, or do you think we
should get into the specifics of what the urgent mechanism is used for
in FTP and telnet?

> - A more detailed description of SeolMa, and its implications, would be
> useful, and I think required in the Security Considerations section.

Please let me know if the change indicated above would do.

> - I feel that further consideration of the proposed solution to SeolMa
> is warranted.

You mean what we propose to fix this NIDS evasion technique?

Thanks!

Kind regards,
-- 
Fernando Gont
e-mail: [email-masked] || [email-masked]
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1

Date: Wed, 15 Sep 2010 18:09:55 +0100
From: Alexey Melnikov <[email-masked]>
To: SM <[email-masked]>, =?ISO-8859-1?Q?=22Martin_J=2E_D=FCrst=22?= <[email-masked]>
Cc: [email-masked]
Subject: Re: [apps-review] Request for review: draft-ietf-geopriv-policy

SM wrote:

> Hi Martin,
> At 21:21 14-09-10, Martin J. D=FCrst wrote:
>
>> Sorry for dropping the ball on this one. I should be able to do a=20
>> review this week, sending it off by the 16th. Is that still worth it?
>
Yes. I think you have time till the end of this month to review it.

> According to the tracker, the draft hasn't completed IESG evaluation.

Indeed.

> It would be good if you could get the review out before the 16th.
>
>> I have looked at this. It has a very long history. It seems to have=20
>> gone into the IESG both in 2007 and in 2009. I'm sure I won't be able=20
>> to take all this into account.
>
Martin, you don't need to do such a comprehensive review - doing=20
detailed review is IESG's job. Peter and I only need to check the=20
document for any typical Apps issues. Of course doing a more detailed=20
review would be Ok with us, but this is not a requirement.

> There are two existing DISCUSSes for this draft.
>
>> There also seems to be a problem with the tracker, in that the=20
>> tracker doesn't seem to be able to handle multiple rounds of IESG=20
>> discussion.
>
It should be able to. What is the problem?

> I see the state change for Lisa that was done on January 20, 2010. =20
> Alexey may know more about whether the position logged are up to date.
>
>> I read "Previous reviews" as "all previous reviews", and expected a=20
>> list. I see there are links to some reviews in the second paragraph.=20
>> That's okay for me, but I'd suggest changing the text of this mail to
>> "Some previous reviews".
>
> Thanks, I'll fix that.

Date: Tue, 14 Sep 2010 23:49:10 -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-geopriv-policy

Hi Martin,
At 21:21 14-09-10, Martin J. D=FCrst wrote:
>Sorry for dropping the ball on this one. I=20
>should be able to do a review this week, sending=20
>it off by the 16th. Is that still worth it?

According to the tracker, the draft hasn't=20
completed IESG evaluation.  It would be good if=20
you could get the review out before the 16th.

>I have looked at this. It has a very long=20
>history. It seems to have gone into the IESG=20
>both in 2007 and in 2009. I'm sure I won't be=20
>able to take all this into account.

There are two existing DISCUSSes for this draft.

>There also seems to be a problem with the=20
>tracker, in that the tracker doesn't seem to be=20
>able to handle multiple rounds of IESG discussion.

I see the state change for Lisa that was done on=20
January 20, 2010.  Alexey may know more about=20
whether the position logged are up to date.

>I read "Previous reviews" as "all previous=20
>reviews", and expected a list. I see there are=20
>links to some reviews in the second paragraph.=20
>That's okay for me, but I'd suggest changing the text of this mail to
>"Some previous reviews".

Thanks, I'll fix that.

Best regards,
-sm=20

Date: Wed, 15 Sep 2010 13:21:50 +0900
From: =?ISO-8859-1?Q?=22Martin_J=2E_D=FCrst=22?= <[email-masked]>
Organization: Aoyama Gakuin University
To: SM <[email-masked]>
Cc: [email-masked]
Subject: Re: [apps-review] Request for review: draft-ietf-geopriv-policy

Hello SM, others,

On 2010/09/02 9:01, SM wrote:
> Hi Martin,
>
> Alexey requested a review of draft-ietf-geopriv-policy before September
> 9, 2010. The request is being assigned to you.

Sorry for dropping the ball on this one. I should be able to do a review 
this week, sending it off by the 16th. Is that still worth it?

> You can find information
> about the author and WG in the datatracker (
> https://datatracker.ietf.org/doc/draft-ietf-geopriv-policy/ ).

I have looked at this. It has a very long history. It seems to have gone 
into the IESG both in 2007 and in 2009. I'm sure I won't be able to take 
all this into account.

There also seems to be a problem with the tracker, in that the tracker 
doesn't seem to be able to handle multiple rounds of IESG discussion.

> Previous
> reviews from the Apps-review Team are accessible at
> http://www.apps.ietf.org/content/apps-review-template

I read "Previous reviews" as "all previous reviews", and expected a 
list. I see there are links to some reviews in the second paragraph. 
That's okay for me, but I'd suggest changing the text of this mail to
"Some previous reviews".

Regards,    Martin.

> The review should be sent to apps-discuss, the author, WG Chair and
> document shepherd, if applicable, and the IESG. The subject of the email
> when submitting the review should be "apps-team review of
> draft-ietf-geopriv-policy".
>
> Thanks,
> -sm
>
>

-- 
#-# Martin J. Dürst, Professor, Aoyama Gakuin University
#-# http://www.sw.it.aoyama.ac.jp   mailto:[email-masked]

Date: Mon, 13 Sep 2010 03:29:39 -0700
To: "Murray S. Kucherawy" <[email-masked]>
From: SM <[email-masked]>
Cc: [email-masked]
Subject: Re: [apps-review] Request for review: draft-ietf-fecframe-framework-10

Hi Murray,
At 23:33 12-09-10, Murray S. Kucherawy wrote:
>That first URL 404s for me.  There's a "/doc" missing after the 
>".org".  Better update your template.  :-)

Thanks.  The correct URL is 
https://datatracker.ietf.org/doc/draft-ietf-fecframe-framework/

>(Other reviewers, that's the fix you need to get to the right page.)

The format to use is https://datatracker.ietf.org/doc/draft-name/ 
where draft-name is the name of the draft without the version number (-10).

Regards,
-sm 

Date: Mon, 13 Sep 2010 09:51:06 +0100
From: Dave Cridland <[email-masked]>
To: The IESG <[email-masked]>, <[email-masked]>, Apps Area Review List <[email-masked]>, Security Area Directorate <[email-masked]>
Subject: [apps-review] SecDir/Apps Review of draft-ietf-tcpm-urgent-data-06

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

In addition, I have been selected as the Apps Reviewer for this =20
document. These comments are similarly written for the benefit of =20
apps area directors, and document editors and WG chairs should treat =20
these comments just like any other last call comments.

I have not made any distinction between the comments.

Summary:

Whilst I agree with the essential premise - that TCP URG is =20
implemented in a different way to that specified, and should be =20
homogenized in favour of the deployed implementations - I feel that =20
both SeolMa and the proposed solution needs to be expanded upon.

Simply dropping TCP Urgent data facilities removes an aspect of TCP =20
which - whilst not commonly used in most modern protocols - is =20
nevertheless still used for useful gain in FTP and TELNET.

Specific recommendations are at the bottom.

Background:

The TCP urgent mechanism, as implemented, means that a single octet =20
is lost when the receiver handles the last "Urgent" data section. =20
Thus particularly when multiple urgent data segments are "in flight", =20
it becomes difficult to guess which octets will be lost by the =20
receiver. The SeolMa attack effectively uses these lost octets to pad =20
strings used in TCP based application protocols, thus defeating na=EFve =20
NIDS pattern matching.

There is no discussion in the draft about SeolMa, indeed there isn't =20
even a mention of it in the Security Considerations. It's not clear =20
to me if the recommendation to use SO_OOBINLINE would have an effect =20
here - my gut feeling is that it would defeat SeolMa by making these =20
"lost" octets part of the normal data flow again.

Cisco's solution relies on simply forcing urgent data to be =20
non-urgent, which will have knock-on effects on TELNET and FTP by =20
default. It's not clear to me from this document (including reading =20
the references)

By instituting a blanket ban, in effect, for TCP Urgent data, this =20
effectively deprecates the entire mechanism. This may prove to be the =20
only solution, however my general feeling is that this may not be the =20
case.

Niggle:

The Cisco-PIX reference does not describe the TCP Urgent behaviour =20
except by implication (it mentions adding rules to allow its use for =20
TELNET and FTP-PI, but that's it). I have a personal distaste for =20
product placement in RFCs, and would prefer that this reference =20
pointed at least at a Cisco paper describing default behaviour, etc.

As an aside, the Cisco instructions actually show the user how to =20
enable urgent data on FTP-DTP, rather than FTP-PI, which is incorrect.

Specific Recommendations:

- An informative reference to FTP and TELNET, noting how and why the =20
URG pointer is used, would make it more obvious what is lost here.

- A more detailed description of SeolMa, and its implications, would =20
be useful, and I think required in the Security Considerations =20
section.

- I feel that further consideration of the proposed solution to =20
SeolMa is warranted.

Dave.

From: "Murray S. Kucherawy" <[email-masked]>
To: SM <[email-masked]>
Date: Sun, 12 Sep 2010 23:33:18 -0700
Accept-Language: en-US
acceptlanguage: en-US
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [apps-review] Request for review: draft-ietf-fecframe-framework-10

> -----Original Message-----
> From: SM [mailto:[email-masked]]
> Sent: Sunday, September 12, 2010 9:45 AM
> To: Murray S. Kucherawy
> Cc: [email-masked]
> Subject: Request for review: draft-ietf-fecframe-framework-10
>=20
> Hi Murray,
> Alexey requested a review of draft-ietf-fecframe-framework-10 before
> September 23, 2010.  The request is being assigned to you.  You can
> find information about the author and WG in the datatracker (
> https://datatracker.ietf.org/draft-ietf-fecframe-framework/
> ).  Previous reviews from the Apps-review Team are accessible at
> http://www.apps.ietf.org/content/apps-review-template

That first URL 404s for me.  There's a "/doc" missing after the ".org".  Be=
tter update your template.  :-)

(Other reviewers, that's the fix you need to get to the right page.)

-MSK

Date: Sun, 12 Sep 2010 09:47:48 -0700
To: Yves Lafon <[email-masked]>
From: SM <[email-masked]>
Cc: [email-masked]
Subject: [apps-review] Request for review: draft-ietf-l3vpn-mvpn-spmsi-joins

Hi Yves,
Alexey requested a review of draft-ietf-l3vpn-mvpn-spmsi-joins-01 
before September 23, 2010.  The request is being assigned to 
you.  You can find information about the author and WG in the 
datatracker ( 
https://datatracker.ietf.org/draft-ietf-l3vpn-mvpn-spmsi-joins/ 
).  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 author, WG Chair and 
document shepherd, if applicable, and the IESG.  The subject of the 
email when submitting the review should be "apps-team review of 
draft-ietf-l3vpn-mvpn-spmsi-joins-01".

Thanks,
-sm

Date: Sun, 12 Sep 2010 09:55:45 -0700
To: Eliot Lear <[email-masked]>
From: SM <[email-masked]>
Cc: [email-masked]
Subject: [apps-review] Request for review: draft-ietf-grow-mrt-13

Hi Elliot,
Alexey requested a review of draft-ietf-grow-mrt-13 before September 
23, 2010.  The request is being assigned to you.  You can find 
information about the author and WG in the datatracker ( 
https://datatracker.ietf.org/draft-ietf-grow-mrt-13/ ).  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 author, WG Chair and 
document shepherd, if applicable, and the IESG.  The subject of the 
email when submitting the review should be "apps-team review of 
draft-ietf-grow-mrt-13".

Thanks,
-sm

Date: Sun, 12 Sep 2010 09:42:50 -0700
To: Ted Hardie <[email-masked]>
From: SM <[email-masked]>
Cc: [email-masked]
Subject: [apps-review] Request for review: draft-mavrogiannopoulos-rfc5081bis-06

Hi Ted,
Alexey requested a review of draft-mavrogiannopoulos-rfc5081bis-06 
before September 23, 2010.  The request is being assigned to 
you.  You can find information about the author and WG in the 
datatracker ( 
https://datatracker.ietf.org/draft-mavrogiannopoulos-rfc5081bis/ 
).  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 author, WG Chair and 
document shepherd, if applicable, and the IESG.  The subject of the 
email when submitting the review should be "apps-team review of 
draft-mavrogiannopoulos-rfc5081bis-06".

Thanks,
-sm

Date: Sun, 12 Sep 2010 09:45:01 -0700
To: "Murray S. Kucherawy" <[email-masked]>
From: SM <[email-masked]>
Cc: [email-masked]
Subject: [apps-review] Request for review: draft-ietf-fecframe-framework-10

Hi Murray,
Alexey requested a review of draft-ietf-fecframe-framework-10 before 
September 23, 2010.  The request is being assigned to you.  You can 
find information about the author and WG in the datatracker ( 
https://datatracker.ietf.org/draft-ietf-fecframe-framework/ 
).  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 author, WG Chair and 
document shepherd, if applicable, and the IESG.  The subject of the 
email when submitting the review should be "apps-team review of 
draft-ietf-fecframe-framework-10".

Thanks,
-sm

Date: Sun, 12 Sep 2010 09:39:56 -0700
To: Eran Hammer-Lahav <[email-masked]>
From: SM <[email-masked]>
Cc: [email-masked]
Subject: [apps-review] Request for review: draft-lundberg-app-tei-xml-03

Hi Eran,
Alexey requested a review of draft-lundberg-app-tei-xml-03 before 
September 30, 2010.  The request is being assigned to you.  You can 
find information about the author and WG in the datatracker ( 
https://datatracker.ietf.org/draft-lundberg-app-tei-xml/ ).  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 author, WG Chair and 
document shepherd, if applicable, and the IESG.  The subject of the 
email when submitting the review should be "apps-team review of 
draft-lundberg-app-tei-xml-03".

Thanks,
-sm

Date: Sun, 12 Sep 2010 09:35:06 -0700
To: Joe Hildebrand <[email-masked]>
From: SM <[email-masked]>
Cc: [email-masked]
Subject: [apps-review] Request for review: draft-ietf-netmod-arch-08

Hi Joe,

Alexey requested a review of draft-ietf-netmod-arch-08 before 
September 23, 2010.  The request is being assigned to you.  You can 
find information about the author and WG in the datatracker ( 
https://datatracker.ietf.org/draft-ietf-netmod-arch/ ).  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 author, WG Chair and 
document shepherd, if applicable, and the IESG.  The subject of the 
email when submitting the review should be "apps-team review of 
draft-ietf-netmod-arch-08".

Thanks,
-sm

Date: Mon, 06 Sep 2010 11:23:49 -0700
To: Claudio Allocchio <[email-masked]>
From: SM <[email-masked]>
Cc: [email-masked]
Subject: Re: [apps-review] Request for review: draft-das-mipshop-andsf-dhcp-options

Hi Claudio,
At 07:53 AM 9/6/2010, Claudio Allocchio wrote:
>.... ops... I posted the review... but I just discovered that for 
>some (unknown) reasons I was unsubscribed from [email-masked] 
>meanhile...
>
>:-(
>
>Ok, I hope the moderator will releae the mail ASAP, while I 
>re-subscribe to the list.

Thanks for reviewing draft-das-mipshop-andsf-dhcp-options-04.  Your 
message to apps-discuss has already been approved ( 
http://www.ietf.org/mail-archive/web/apps-discuss/current/msg01724.html ).

Best regards,
-sm  

Date: Mon, 6 Sep 2010 16:53:55 +0200 (CEST)
From: Claudio Allocchio <[email-masked]>
To: Alexey Melnikov <[email-masked]>
Cc: [email-masked], Claudio Allocchio <[email-masked]>
Subject: Re: [apps-review] Request for review: draft-das-mipshop-andsf-dhcp-options

.... ops... I posted the review... but I just discovered that for some 
(unknown) reasons I was unsubscribed from [email-masked] 
meanhile...

:-(

Ok, I hope the moderator will releae the mail ASAP, while I re-subscribe 
to the list.

all the best!

Claudio

--------

>From [email-masked] Mon Sep  6 16:41:02 2010
Date: Mon, 06 Sep 2010 07:40:28 -0700
From: [email-masked]
To: [email-masked]
Subject: Your message to apps-discuss awaits moderator approval

Your mail to 'apps-discuss' with the subject

     apps-team review of draft-das-mipshop-andsf-dhcp-options

Is being held until the list moderator can review it for approval.

The reason it is being held:

     Post by non-member to a members-only list

Either the message will get posted to the list, or you will receive
notification of the moderator's decision.  If you would like to cancel
this posting, please visit the following URL:

     https://www.ietf.org/mailman/confirm/apps-discuss/a21d2539060a65e46efb897d8497ba538040d350

------------------------------------------------------------------------------
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: Thu, 02 Sep 2010 11:02:13 +0100
From: Alexey Melnikov <[email-masked]>
To: Claudio Allocchio <[email-masked]>
Cc: [email-masked]
Subject: Re: [apps-review] Request for review: draft-das-mipshop-andsf-dhcp-options

Claudio Allocchio wrote:

> I though you wanted a full revision of the DHCP-related options, hence 
> my objection. ;-)

No, this is the job of IESG.

Date: Thu, 2 Sep 2010 11:34:41 +0200 (CEST)
From: Claudio Allocchio <[email-masked]>
To: Alexey Melnikov <[email-masked]>
Cc: [email-masked], Claudio Allocchio <[email-masked]>
Subject: Re: [apps-review] Request for review: draft-das-mipshop-andsf-dhcp-options

On Thu, 2 Sep 2010, Alexey Melnikov wrote:

> Claudio Allocchio wrote:
>
>> Hello,
>
> Hi Claudio,
>
>> On Wed, 1 Sep 2010, SM wrote:
>> 
>>> Hi Claudio,
>>> 
>>> Alexey requested a review of draft-das-mipshop-andsf-dhcp-options before 
>>> September 9, 2010.  The request is being assigned to you.  You can find 
>>> information about the author and WG in the datatracker ( 
>>> https://datatracker.ietf.org/doc/draft-das-mipshop-andsf-dhcp-options/ ). 
>>> Previous reviews from the Apps-review Team are accessible at 
>>> http://www.apps.ietf.org/content/apps-review-template
>> 
>> I had a quick look to the draft, and I'm not sure I can fully review a 
>> number of the technical details in the specification. My expertise in 
>> "mobility" is much more related to "mail and messaging" protocols in mobile 
>> devices, while this seems much more close to network layer options.
>
> If you can just have a quick scan of the document to see if there are any 
> Apps issues: use of XML, date/time, URIs, Internationalization, IDNA, etc, 
> that would be greatly appreciated. No need to be an expert in mobility.

OK, this I can do for sure!

I though you wanted a full revision of the DHCP-related options, hence my 
objection. ;-)

>
>> Are you sure we do not have a more expert reviwer in the pool? If not, I 
>> can do it.
>> 
>> Let me know!
>> 
>>> The review should be sent to apps-discuss, the author, WG Chair and 
>>> document shepherd, if applicable, and the IESG.  The subject of the email 
>>> when submitting the review should be "apps-team review of 
>>> draft-das-mipshop-andsf-dhcp-options".
>>> 
>>> Thanks,
>>> -sm
>> 
>
>

------------------------------------------------------------------------------
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: Thu, 02 Sep 2010 10:27:22 +0100
From: Alexey Melnikov <[email-masked]>
To: Claudio Allocchio <[email-masked]>
Cc: [email-masked]
Subject: Re: [apps-review] Request for review: draft-das-mipshop-andsf-dhcp-options

Claudio Allocchio wrote:

> Hello,

Hi Claudio,

> On Wed, 1 Sep 2010, SM wrote:
>
>> Hi Claudio,
>>
>> Alexey requested a review of draft-das-mipshop-andsf-dhcp-options 
>> before September 9, 2010.  The request is being assigned to you.  You 
>> can find information about the author and WG in the datatracker ( 
>> https://datatracker.ietf.org/doc/draft-das-mipshop-andsf-dhcp-options/ 
>> ). Previous reviews from the Apps-review Team are accessible at 
>> http://www.apps.ietf.org/content/apps-review-template
>
> I had a quick look to the draft, and I'm not sure I can fully review a 
> number of the technical details in the specification. My expertise in 
> "mobility" is much more related to "mail and messaging" protocols in 
> mobile devices, while this seems much more close to network layer options.

If you can just have a quick scan of the document to see if there are 
any Apps issues: use of XML, date/time, URIs, Internationalization, 
IDNA, etc, that would be greatly appreciated. No need to be an expert in 
mobility.

> Are you sure we do not have a more expert reviwer in the pool? If not, 
> I can do it.
>
> Let me know!
>
>> The review should be sent to apps-discuss, the author, WG Chair and 
>> document shepherd, if applicable, and the IESG.  The subject of the 
>> email when submitting the review should be "apps-team review of 
>> draft-das-mipshop-andsf-dhcp-options".
>>
>> Thanks,
>> -sm
>

Date: Thu, 2 Sep 2010 10:34:23 +0200 (CEST)
From: Claudio Allocchio <[email-masked]>
To: SM <[email-masked]>
Cc: Claudio Allocchio <[email-masked]>, [email-masked]
Subject: Re: [apps-review] Request for review: draft-das-mipshop-andsf-dhcp-options

Hello,

On Wed, 1 Sep 2010, SM wrote:

> Hi Claudio,
>
> Alexey requested a review of draft-das-mipshop-andsf-dhcp-options before 
> September 9, 2010.  The request is being assigned to you.  You can find 
> information about the author and WG in the datatracker ( 
> https://datatracker.ietf.org/doc/draft-das-mipshop-andsf-dhcp-options/ ). 
> Previous reviews from the Apps-review Team are accessible at 
> http://www.apps.ietf.org/content/apps-review-template

I had a quick look to the draft, and I'm not sure I can fully review a 
number of the technical details in the specification. My expertise in 
"mobility" is much more related to "mail and messaging" protocols in 
mobile devices, while this seems much more close to network layer options.

Are you sure we do not have a more expert reviwer in the pool? If not, I 
can do it.

Let me know!

> The review should be sent to apps-discuss, the author, WG Chair and document 
> shepherd, if applicable, and the IESG.  The subject of the email when 
> submitting the review should be "apps-team review of 
> draft-das-mipshop-andsf-dhcp-options".
>
> Thanks,
> -sm
>
>

------------------------------------------------------------------------------
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: Wed, 01 Sep 2010 17:03:41 -0700
To: Carsten Bormann <[email-masked]>
From: SM <[email-masked]>
Cc: [email-masked]
Subject: [apps-review] Request for review: draft-ietf-netmod-arch

Hi Carsten,

Alexey requested a review of draft-ietf-netmod-arch before September 
9, 2010.  The request is being assigned to you.  You can find 
information about the author and WG in the datatracker ( 
https://datatracker.ietf.org/doc/draft-ietf-netmod-arch/ ).  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 author, WG Chair and 
document shepherd, if applicable, and the IESG.  The subject of the 
email when submitting the review should be "apps-team review of 
draft-ietf-netmod-arch".

Thanks,
-sm

Date: Wed, 01 Sep 2010 17:40:16 -0700
To: [email-masked]
From: S Moonesamy <[email-masked]>
Cc: [email-masked]
Subject: [apps-review] Apps Area Review Team Report for August 2010

Hello,

The Applications Area Review Team provides semi-formal reviews of 
Internet-Drafts as a way to improve the quality of IETF 
specifications.  The members of the team are selected from the IETF 
community, especially from among active participants and recognized 
experts in the Applications Area.

The following reviews have been performed in August 2010:

  draft-gennai-smime-cnipa-pec-08 was reviewed by Dave Crocker.

Pending reviews:

  draft-ietf-netmod-dsdl-map-05 assigned to Aaron Stone
  draft-ietf-ecrit-lost-sync-08 assigned to Aaron Stone

Regards,
S. Moonesamy
On behalf of the Apps Review Team
http://www.apps.ietf.org/content/applications-area-review-team

Date: Wed, 01 Sep 2010 16:57:29 -0700
To: Vijay Gurbani <[email-masked]>
From: SM <[email-masked]>
Cc: [email-masked]
Subject: [apps-review] Request for review: draft-ietf-geopriv-arch

Hi Vijay,

Alexey requested a review of draft-ietf-geopriv-arch before September 
9, 2010.  The request is being assigned to you.  You can find 
information about the author and WG in the datatracker ( 
https://datatracker.ietf.org/doc/draft-ietf-geopriv-arch/ 
).  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 author, WG Chair and 
document shepherd, if applicable, and the IESG.  The subject of the 
email when submitting the review should be "apps-team review of 
draft-ietf-geopriv-arch".

Thanks,
-sm

Date: Wed, 01 Sep 2010 16:52:52 -0700
To: Dave Cridland <[email-masked]>
From: SM <[email-masked]>
Cc: [email-masked]
Subject: [apps-review] Request for review: draft-ietf-fecframe-sdp-elements

Hi Dave,

Alexey requested a review of draft-ietf-fecframe-sdp-elements before 
September 9, 2010.  The request is being assigned to you.  You can 
find information about the author and WG in the datatracker ( 
https://datatracker.ietf.org/doc/draft-ietf-fecframe-sdp-elements/ 
).  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 author, WG Chair and 
document shepherd, if applicable, and the IESG.  The subject of the 
email when submitting the review should be "apps-team review of 
draft-ietf-fecframe-sdp-elements".

Thanks,
-sm

Date: Wed, 01 Sep 2010 16:49:25 -0700
To: Claudio Allocchio <[email-masked]>
From: SM <[email-masked]>
Cc: [email-masked]
Subject: [apps-review] Request for review: draft-das-mipshop-andsf-dhcp-options

Hi Claudio,

Alexey requested a review of draft-das-mipshop-andsf-dhcp-options 
before September 9, 2010.  The request is being assigned to you.  You 
can find information about the author and WG in the datatracker ( 
https://datatracker.ietf.org/doc/draft-das-mipshop-andsf-dhcp-options/ 
).  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 author, WG Chair and 
document shepherd, if applicable, and the IESG.  The subject of the 
email when submitting the review should be "apps-team review of 
draft-das-mipshop-andsf-dhcp-options".

Thanks,
-sm

Date: Wed, 01 Sep 2010 17:01:55 -0700
To: Martin =?iso-8859-1?Q?D=FCrst?= <[email-masked]>
From: SM <[email-masked]>
Cc: [email-masked]
Subject: [apps-review] Request for review: draft-ietf-geopriv-policy

Hi Martin,

Alexey requested a review of draft-ietf-geopriv-policy before 
September 9, 2010.  The request is being assigned to you.  You can 
find information about the author and WG in the datatracker ( 
https://datatracker.ietf.org/doc/draft-ietf-geopriv-policy/ 
).  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 author, WG Chair and 
document shepherd, if applicable, and the IESG.  The subject of the 
email when submitting the review should be "apps-team review of 
draft-ietf-geopriv-policy".

Thanks,
-sm