Tom Taylor | 22 May 02:53 2015
Picon

Last Call review of draft-ietf-sfc-architecture-08

I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at

<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Please resolve these comments along with any other Last Call comments
you may receive.

Document: draft-ietf-sfc-architecture-08
Reviewer: Tom Taylor
Review Date:        2015-05-17
IETF LC End Date:   2015-05-25
IESG Telechat date: 2015-05-28

Summary:

There is one IPR declaration, which was repeated for two predecessor 
documents but not for the current draft. The draft is basically ready to 
go with a very minor issue and a few nits.

Major issues:

Minor issues:

The Security Considerations section rightly mentions the need to avoid 
leaking SFC information. However, it does this under the heading of 
"Classification". Could I suggest that the first two sentences of the 
"Classification" bullet be separated out under the title "Boundaries"?

Nits/editorial comments:
(Continue reading)

A. Jean Mahoney | 21 May 22:55 2015

Assignments for the 2015-05-28 Telechat

Hi all,

The following reviewers have assignments:

Reviewer            LC end       Draft
----------------------------------------------------------------------------------
Alexey Melnikov     2015-04-20 draft-ietf-bmwg-traffic-management-04
Alexey Melnikov     2015-02-27   draft-ietf-pim-rfc4601bis-05 *
Alexey Melnikov     2015-05-04 draft-ietf-ipsecme-ikev2-null-auth-06 **

Christer Holmberg   2015-05-06 
draft-ietf-dhc-dynamic-shared-v4allocation-07 *

David Black         2015-04-20   draft-ietf-v6ops-cidr-prefix-02 *

Dan Romascanu       2015-05-07   draft-ietf-dane-smtp-with-dane-17 *

Francis Dupont      2015-03-18 draft-ietf-ccamp-wson-signaling-12 *

Joel Halpern        2015-05-14   draft-ietf-kitten-sasl-oauth-22 **

Meral Shirazipour   2015-04-16   draft-ietf-nfsv4-layout-types-03 **
Meral Shirazipour   2015-05-15 draft-ietf-rtcweb-stun-consent-freshness-13 *

Martin Thomson      2015-05-15 draft-ietf-manet-olsrv2-multitopology-05

Peter Yee           2015-05-15   draft-ietf-siprec-protocol-16 **

Russ Housley        2015-06-03   draft-ietf-rtcweb-video-05 **, ***

(Continue reading)

A. Jean Mahoney | 21 May 22:44 2015

A *new* batch of IETF LC reviews - 2015-05-21

Hi all,

The following reviewers have assignments:

Reviewer          LC end       Draft
---------------------------------------------------------------------
Alexey Melnikov   2015-06-01   draft-ietf-oauth-spop-11

Brian Carpenter   2015-06-01   draft-ietf-dime-congestion-flow-attributes-01

Christer Holmberg 2015-06-03   draft-ietf-httpbis-tunnel-protocol-04

Dan Romascanu     2015-05-03   draft-ietf-xmpp-6122bis-22

Wassim Haddad     2015-06-01   draft-ietf-oauth-introspection-08

I have made the assignments in the review tool:
http://art.tools.ietf.org/tools/art/genart/

And the assignments are captured in the spreadsheets:
http://wiki.tools.ietf.org/dav/genart/gen-art.html
http://wiki.tools.ietf.org/dav/genart/gen-art-by-reviewer.html

The standard template is included below.

Thanks,

Jean

-------------------------------------------------------------------
(Continue reading)

Roni Even | 20 May 17:59 2015
Picon

Gen_ART LC review of draft-ietf-tcpm-newcwv-10

I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Please resolve these comments along with any other Last Call comments you may receive.

Document:  draft-ietf-tcpm-newcwv-10

Reviewer: Roni Even

Review Date:2015–5-20

IETF LC End Date: 2015–5-22

IESG Telechat date:

 

Summary: This draft is ready for publication as an Experimental RFC.

Major issues:

Minor issues:

 

Nits/editorial comments:

  1. I am not sure that there is a need for the first sentence in section 1.2

  2. In section 4.4.1 MSS is used but not expanded Maximum Segment  Size (MSS)

 

_______________________________________________
Gen-art mailing list
Gen-art <at> ietf.org
https://www.ietf.org/mailman/listinfo/gen-art
Francis Dupont | 17 May 15:05 2015
Picon

review of draft-ietf-straw-b2bua-stun-06.txt

I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at

<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Please resolve these comments along with any other Last Call comments
you may receive.

Document: draft-ietf-straw-b2bua-stun-06.txt
Reviewer: Francis Dupont
Review Date: 20150515
IETF LC End Date: 20150513
IESG Telechat date: 20150514??

Summary: Ready

Major issues: None

Minor issues: None

Nits/editorial comments:
 I reviewed the 06 version.

 - 1 page 3: signalling -> signaling

 - 4.1 page 5: after the terminology section it is recommended to avoid
  lower case keywords (e.g., the may in "A B2BUA may be in").

 - 4.4 page 11: a may and a should...

 - authors' addresses pages 13 and 14: India is the full country name,
  US the ISO IS 3166 code (the full name is USA). The current rule
  is to use 3166 two letter codes, I raised a concern as the UPU
  has the opposite rule (full names). Let the RFC Editor to handle this?

Regards

Francis.Dupont <at> fdupont.fr
Russ Housley | 15 May 17:14 2015

Gen-ART Review of draft-ietf-rtcweb-video-05

I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at
<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

This review is in response to a request for early Gen-ART review.

Document: draft-ietf-rtcweb-video-05
Reviewer: Russ Housley
Review Date: 2015-05-15
IETF LC End Date: 2015-04-28
IESG Telechat date: unknown

Summary: Almost Ready

Major Concerns:

Downref: There is a normative reference to Informational RFC 6386.
There is no mention of the downref in the IETF Last Call, and
RFC 6386 is not listed in the downref registry.
(https://trac.tools.ietf.org/group/iesg/trac/wiki/DownrefRegistry).

Minor Concerns:

In section 3, the first sentence says: "This section provides guidance
on pre- or post-processing of video streams."  s/pre- or/pre- and/

Maybe the intended audience will understand "Y'CbCr 4:2:0", but a
reference would have helped me.  I found useful information at
http://en.wikipedia.org/wiki/Chroma_subsampling.

The indented text in Section 5 should begin with "NOTE: ".

In section 6, I assume that "320x240" is measured in pixels.  Please
make the text clear.

Section 6.2 says: "Unless otherwise signaled, implementations that use
H.264 MUST encode and decode pixels with a implied 1:1 (square) aspect
ratio."  Isn't this true for VP8 as well?

Other Comments:

There are references to several outdated I-Ds.  Some of the references
point to particular section numbers.  I did not check whether the
updates had an impact on these sections, but someone should do so:
  - draft-ietf-payload-vp8-11: -15 exists
  - draft-ietf-rtcweb-overview-12: -13 exists
  - draft-ietf-rtcweb-rtp-usage-06: -23 exists
  - draft-ietf-rtcweb-security-arch-09: -11) exists
  - draft-ietf-rtcweb-security-06: -08 exists
Vijay K. Gurbani | 15 May 17:07 2015

Gen-ART review of draft-ietf-mip4-multiple-tunnel-support-12

I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at
<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Please resolve these comments along with any other Last Call comments
you may receive.

Document: draft-ietf-mip4-multiple-tunnel-support-12
Reviewer: Vijay K. Gurbani
Review Date: May-15-2015
IETF LC End Date: May-25-2015
IESG Telechat date: Not known

This document is ready as an Experimental Standard.  A couple of points
below need addressing, though.

Major: 0
Minor: 2
Nits:  1

Minor:
1/ S4.1, second paragraph: "This extension is a non-skippable extension
    and MAY be added by the mobile node to the Registration Request
    message."

    Two comments.

    First, does "non-skippable" mean "MUST be present"?  If so, why "non-
    skippable"?  At least I have not seen such a phrase in an IETF
    document before.  My suggestion would be to simply say that "This
    extension MUST be present and ..."

    Which brings us to the second comment.

    "... and MAY be added by the mobile node ..."  This extension is
    "non-skippable" (?) but a mobile node MAY add it.  If the extension
    is "non-skippable", then why the MAY?

    Furthermore, if the intent is for some other entity to add this
    extension if the mobile node does not (hence the justification of
    MAY), then you should spell out who this entity is.  (Sort of
    how you do it in S4.2, second paragraph, which contains almost
    identical language to above without the qualifying last phrase
    that informs the reader who will add the extension if not the
    mobile node.)

2/ S4.2, second paragraph: Consider changing the "non-skippable"
    to "MUST be present" (c.f., above comment).

Nits:
1/ S2.2, the following sentence does not read well:
    A mobile node, when it registers multiple bindings with its home
    agent, each using different care-of addresses, then each of those
    bindings are given a unique identifier.

  Suggested text:

    When a mobile node registers multiple bindings with its home
    agent, each using a different care-of address, then each of those
    bindings are given a unique identifier.

Thanks,

- vijay
--

-- 
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA)
Email: vkg <at> {bell-labs.com,acm.org} / vijay.gurbani <at> alcatel-lucent.com
Web: http://ect.bell-labs.com/who/vkg/  | Calendar: http://goo.gl/x3Ogq
A. Jean Mahoney | 14 May 21:12 2015

A *new* batch of IETF LC reviews - 2015-05-14

Hi all,

The following reviewers have assignments:

Reviewer          LC end       Draft
---------------------------------------------------------------------
Roni Even         2015-05-22  draft-ietf-tcpm-newcwv-10

Russ Housley      2015-05-28  draft-ietf-rtcweb-video-05 *

Suresh Krishnan   2015-05-28  draft-ietf-rtcweb-rtp-usage-23 *

Tom Taylor        2015-05-25  draft-ietf-sfc-architecture-07 *

Vijay Gurbani     2015-05-25  draft-ietf-mip4-multiple-tunnel-support-12

* Also on the 5/28 telechat

I have made the assignments in the review tool:
http://art.tools.ietf.org/tools/art/genart/

And the assignments are captured in the spreadsheets:
http://wiki.tools.ietf.org/dav/genart/gen-art.html
http://wiki.tools.ietf.org/dav/genart/gen-art-by-reviewer.html

The standard template is included below.

Thanks,

Jean

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

I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at

<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Please resolve these comments along with any other Last Call comments
you may receive.

Document:
Reviewer:
Review Date:
IETF LC End Date:
IESG Telechat date: (if known)

Summary:

Major issues:

Minor issues:

Nits/editorial comments:
Elwyn Davies | 12 May 12:06 2015

Gen-art telechat review of draft-ietf-scim-core-schema-19

I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at
< http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Please wait for direction from your document shepherd
or AD before posting a new version of the draft.

Document: draft-ietf-scim-core-schema-19.txt
Reviewer: Elwyn Davies
Review Date: 2015/05/12
IETF LC End Date: 2015/04/20
IESG Telechat date: 2015/05/14

Summary: Ready.  Thanks to Phil Hunt and the other authors for 
addressing the comments from my last call review in versions -18 and  -19.

[For future reference: the IETF needs to consider representation of 
names and addresses in a more culturally sensitive format in future work 
(C.f. current work on xml2rfc). Mapping to existing systems limits the 
possibilities for SCIM but we should try to avoid ossification if at all 
possible.]
Tom Taylor | 11 May 00:37 2015
Picon

Pre-telechat review of draft-ietf-manet-tlv-naming-02

This was supposed to be done by May 1, but got buried in my Inbox. My 
apologies.

I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at

<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Please resolve these comments along with any other Last Call comments
you may receive.

Document: draft-ietf-manet-tlv-naming-02
Reviewer: Tom Taylor
Review Date:        10 May 2015
IETF LC End Date:    1 May 2015
IESG Telechat date: 14 May 2015

Summary: This document has minor issues that need to be resolved, along 
with a few nits.

Major issues:

Minor issues:

1. If the requested TLV Type does not immediately define all the 
corresponding type extensions for versions of that type, the Expert 
Reviewer or IANA will be faced with the task of choosing an appropriate 
Type value within which to place the extension. No guidance has been 
provided for this purpose. What is the intention?

2. No IANA Considerations have been provided for the following registries:
     TC Message-Type-specific Message TLV Types
     TC Message-Type-specific Address Block TLV Types
     HELLO Message-Type-specific Message TLV Types
     HELLO Message-Type-specific Address Block TLV Types
     SMF_TYPE Message TLV Type Extensions
     SMF_NBR_TYPE Address Block TLV Type Extensions

Nits/editorial comments:

Sec. 1, third from last paragraph: s/consisteng/consistent/

Sec. 3.1, s/reguested/requested/ (both outer bullets, first line of each)

IANA Considerations, following Table 11: the current registry name is 
"ICV[TIMESTAMP] Address TLV Type Extensions" (missing the word "Block"). 
This is inconsistent with the other address block TLV types. I suggest, 
in place of the current text for these two extension registries, text to 
resolve the inconsistency, as follows:

OLD

    The IANA Registry "ICV[TIMESTAMP] Address Block TLV Type Extensions"
    is unchanged.

NEW

    The IANA Registry "ICV[TIMESTAMP] Address TLV Type Extensions" is
    unchanged except to add the word "Block" after "Address" in the
    registry name.

IANA Considerations, Table 13 and preceding text: the current registry 
name is "NBR_ADDR_TYPE ....". This document refers to it as 
"NBR_ADDR_TYPES ...." (i.e., plural). The inconsistency needs to be 
resolved.
Black, David | 10 May 21:43 2015

Gen-ART and OPS-Dir review of draft-ietf-mmusic-rtsp-nat-evaluation-15

Well, it's been almost a year since the review of the -14 version, but the draft
has now been revised, and significantly improved.

Document: draft-ietf-mmusic-rtsp-nat-evaluation-15
Reviewer: David L. Black
Review Date: May 10, 2015
IESG Telechat Date: May 14, 2015

Summary: This draft is almost ready for publication, but has nits that
should be corrected before publication.  

The -15 version has significant changes in response to the Gen-ART/OPS-Dir
review of the -14 version, e.g., addition of quite a bit of new text on ALG
considerations.  The two major issues from the review have been resolved
as follows:

> [1] The abstract characterizes this draft as the evaluation that lead to
> the mmusic WG's choice of the NAT traversal technique for RTSP, but
> the evaluation in this draft did not drive that choice,

The title change to the draft, plus several other text changes, notably
to the first sentence of the second paragraph of Section 4, suffice to
address this concern.

> [2] (problems with vague descriptions of mechanisms)

The RTP No-OP discussion has been significantly rewritten and text has
been added Section 4.1.1 on STUN characterization of NATs to address
this vagueness concern.

All of the minor issues have been addressed.

-- Editorial Comments:

Section 4.6.5

OLD
	The three way latching is significantly securer than
NEW
	Three way latching is significantly more secure than

I saw a number of other editorial items in the newly added text that
I'll leave to the RFC Editor.

idnits 2.13.02 found an obsolete reference:

  -- Obsolete informational reference (is this intentional?): RFC 3489
     (Obsoleted by RFC 5389)

This is intentional, as the draft refers to an obsolete STUN feature
in that obsolete RFC, so this idnits complaint can be ignored.

Thanks,
--David

> -----Original Message-----
> From: Black, David
> Sent: Saturday, June 14, 2014 10:57 PM
> To: Magnus Westerlund (magnus.westerlund <at> ericsson.com); thomas.zeng <at> gmail.com;
> General Area Review Team (gen-art <at> ietf.org); ops-dir <at> ietf.org
> Cc: mmusic <at> ietf.org; ietf <at> ietf.org; Black, David
> Subject: Gen-ART and OPS-Dir review of draft-ietf-mmusic-rtsp-nat-evaluation-
> 14
> 
> This is a combined Gen-ART and OPS-DIR review.
> Boilerplate for both follows ...
> 
> I am the assigned Gen-ART reviewer for this draft. For background on
> Gen-ART, please see the FAQ at
> 
> <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
> 
> Please resolve these comments along with any other Last Call comments
> you may receive.
> 
> I have reviewed this document as part of the Operational directorate's ongoing
> effort to review all IETF documents being processed by the IESG.  These
> comments
> were written primarily for the benefit of the operational area directors.
> Document editors and WG chairs should treat these comments just like any other
> last call comments.
> 
> Document: draft-ietf-mmusic-rtsp-nat-evaluation-14
> Reviewer: David L. Black
> Review Date: June 14, 2014
> IETF LC End Date: June 13, 2014
> 
> Summary: This draft is on the right track, but has open issues
> 		described in the review.
> 
> This draft describes and evaluates a number of proposed NAT traversal
> mechanisms for RTSP.  The draft covers a lot of detailed material
> about the proposed mechanisms, and necessarily assumes that the reader
> has some reasonable familiarity with NAT and RTP concepts.
> 
> Major issues:
> 
> [1] The abstract characterizes this draft as the evaluation that lead to
> the mmusic WG's choice of the NAT traversal technique for RTSP, but
> the evaluation in this draft did not drive that choice, as indicated
> in Section 6:
> 
>    Looking at Figure 1 one would draw the conclusion that using TCP
>    Tunneling or Three-Way Latching is the solutions that best fulfill
>    the requirements.  The different techniques were discussed in the
>    MMUSIC WG.  It was established that the WG would pursue an ICE based
>    solution due to its generality and capability of handling also
>    servers delivering media from behind NATs.
> 
> OTOH, there appears to be a lot  of useful material in this draft that
> should be published in an informational RFC, not only the comparison, of
> NAT traversal techniques, but also documentation of some of those
> techniques, as indicated in Section 4:
> 
>    This section includes NAT traversal techniques that
>    have not been formally specified anywhere else.  The overview section
>    of this document may be the only publicly available specification of
>    some of the NAT traversal techniques.
> 
> This may be fairly simple to address, as the last sentence in the
> abstract and the Section 6 text quoted above are the primary sources
> of this issue.  It may also help to change the title of this draft
> from "The Evaluation of ..." to "Comparison of ..." and do something
> analogous to other occurrences of the word "evaluation" in this draft.
> 
> Also in the text quoted from section 4 above "overview section" is
> misleading, as the documentation is in Section 4 - I suggest deleting
> "The overview section of". [Editorial]
> 
> [2] Section 4 says:
> 
>    Some other techniques have been recommended against or are no longer
>    possible due to standardization works' outcome or their failure to
>    progress within IETF after the initial evaluation in this document,
>    e.g.  RTP No-Op [I-D.ietf-avt-rtp-no-op].
> 
> That's too vague, an explicit list should be provided of techniques in
> Section 4 that should not or cannot currently be used, starting with RTP
> No-Op including an explanation of why that is the case for each technique.
> There's also an important editorial clarification needed - these
> "other techniques" are not NAT traversal techniques; they are possible
> elements of some NAT traversal techniques.
> 
> This text is 4.1.1 is part of this issue:
> 
>    The first version of STUN [RFC3489] included categorization and
>    parameterization of NATs.  This was abandoned in the updated version
>    [RFC5389] due to it being unreliable and brittle.  Some of the below
>    discussed methods are based on RFC3489 functionality which will be
>    called out and the downside of that will be part of the
>    characterization.
> 
> Minor issues:
> 
> [A] Firewall paragraph in Introduction confuses ALG implementation with
> firewall configuration (presumably UDP pinholes).  It needs to clearly
> separate those two concepts, as the current text implies that punching
> a UDP (pin)hole is part of the firewall implementation, whereas it's
> actually part of the operational configuration of the firewall.
> 
> [B] Still in the Introduction (Section 1):
> 
>    At the time when the bulk of work on this document was done, a single
>    level of NAT was the dominant deployment for NATs, and multiple level
>    of NATs, including Carrier Grade NATs (CGNs) has been only partially
>    considered.
> 
> That's vague - please provide a clear statement of what is out of scope for
> this draft.  It looks like everything other than Basic NAT techniques is
> out of scope.
> 
> -- Section 1.2
> [C]
>    Many organizations
>    use firewalls to prevent privacy intrusions and malicious attacks to
>    corporate computing resources in the private intranet [RFC2588].
> 
> Please remove the word "privacy" - I don't believe it's correct in this
> context, as many of the intrusions are intended to compromise far more than
> privacy. I would also change "to prevent" -> "to counter" as many current
> attacks are not prevented by firewalls.
> 
> This needs more explanation:
> 
>    2.  NAT does not in itself provide security, although some access
>        control policies can be implemented using address translation
>        schemes.  The inherent filtering behaviours are commonly mistaken
>        for real security policies.
> 
> At a minimum, explain what sort of "security" is not provided.  In addition,
> I suggest noting that a NAT can provide some privacy by concealing
> address/port
> usage on the private side of the NAT.
> 
> [D] Still in Section 1.2:
> 
>    In the rest of this memo we use the phrase "NAT traversal"
>    interchangeably with "firewall traversal", and "NAT/firewall
>    traversal".
> 
> No, don't do that, please.  This is a NAT traversal document that considers
> the effects of NAT traversal techniques on firewalls, so the term "NAT
> traversal" should be the primary term.
> 
> -- Section 2, last paragraph.
> [E]
>    Note that if neither RTCP packets nor RTSP
>    messages are received by the RTSP server for a while, the RTSP server
>    has the option to delete the corresponding RTP session, SSRC and RTSP
>    session ID, because either the client can not get through a middle
>    box NAT/firewall, or the client is mal-functioning.
> 
> Is there any delay recommended before RTSP server reuse of that set of
> identifying information (RTP session, SSRC and RTSP session ID)?
> 
> -- Section 3
> [F]
>    3.  Should have minimal impact on clients not behind NATs and which
>        are not dual-hosted.  RTSP dual-hosting means that the RTSP
>        signalling protocol and the media protocol (e.g.  RTP) are
>        implemented on different computers with different IP addresses.
> 
>        *  For instance, no extra delay from RTSP connection till arrival
>           of media
> 
> By comparison to requirement R3 in Section 6, the above text is too broad.
> The R3 requirement considered in this draft is specifically about additional
> protocol round trips; "extra delay" could be introduced for other reasons.
> 
> [G] Still in Section 3
> 
>    4.  Should be simple to use/implement/administer so people actually
>        turn them on
> 
>        *  Otherwise people will resort to TCP tunneling through NATs
> 
> Not so fast ... TCP tunneling is one of the evaluated techniques (see
> Section 4.8), so that text isn't right.  Deletion of the
> "* Otherwise ..." sub-bullet should suffice to deal with this.
> 
> [H] Still in Section 3
> 
>    5.  Should authenticate dual-hosted client transport handler to
>        prevent DDoS attacks.
> 
> What's a "dual-hosted client transport handler" ???  I suggest adding
> this term and dual-hosting/dual-hosted to the Glossary in Section 1.3.
> 
> [I] Still in Section 3
> 
>    Note a simple preventative measure commonly
>    deployed is for the RTSP server to disallow the cases where the
>    client's RTP receiver has a different IP address than that of the
>    RTSP client.  With the increased deployment of NAT middleboxes by
>    operators, i.e. carrier grade NAT (CGN), the reuse of an IP address
>    on the NAT's external side by many customers reduces the protection
>    provided.  Also in some applications (e.g., centralized
>    conferencing), dual-hosted RTSP/RTP clients have valid use cases.
>    The key is how to authenticate the messages exchanged during the NAT
>    traversal process.
> 
> Is that "measure commonly deployed" recommended?  The above text chunk
> feels like Security Considerations text, and this text could usefully
> be moved to Section 8.
> 
> [J] Section 4.1.1 relies on STUN's abandoned NAT type classification
> functionality to determine where to send the hole-punching UDP packets.
> What's wrong with always sending those packets to the "server's source
> address/port"?  That should work for both types of NATs, thereby removing
> the dependency on STUN classification of NAT types.
> 
> [K] Why are ALG considerations only applicable to STUN-based techniques?
> 
> -- Section 4.3.4 Disadvantages list
> [L]
>    o  Assumes that it is possible to de-multiplex between the packets of
>       the media protocol and STUN packets.
> 
> That is actually possible, although the demux technique is not exactly
> elegant Add a pointer to Section 5.1.2 of RFC 5764 for information on
> how this can be done.
> 
> -- Section 4.4.1
> [M]
>    Latching [I-D.ietf-mmusic-latching] is a NAT traversal solution that
>    is based on requiring RTSP clients to send UDP packets to the
>    server's media output ports.
> 
> Well, draft-ietf-mmusic-latching is about to be approved for publication
> as an RFC, but it does not apply to RTSP.  Additional RTSP extension work
> would be required, as specified in section 4.4.2. Please make that clear
> at the start of this section, and include a forward pointer to section 4.4.2.
> 
> [N] Section 4.6 - Where are the security considerations for 3-way Latching?
> 
> -- Section 4.8.4
> [O]
>    It is not possible to
>    get any amplification effect for denial of service attacks due to
>    TCP's flow control.
> 
> That's not correct or at least not a complete discussion of denial of service
> possibilities - if an attacker can cause a lot of TCP SYNs to be sent to a
> target/victim, the result can be a DDoS attack.  The text quoted above needs
> to be rewritten to address this possibility.
> 
> Nits/editorial comments:
> 
> There are additional editorial cleanups that I'll leave to the RFC Editor,
> but I noted a few things that seem to deserve mention here:
> 
> - Section 1, 1st paragraph
> 
>    Today there is a proliferate deployment of different flavors of
> 
> "proliferate" -> "proliferating", "flavors" -> "types"
> 
> -- Section 1.1:
> 
>    "This document uses the term "address and port mapping" as the
>    translation between an external address and port and an internal
>    address and port.  Note that this is not the same as an "address
>    binding" as defined in RFC 2663."
> 
>       Note: In the above it would be more correct to use external
>       instead of public in the above text.  The external IP address is
>       commonly a public one, but might be of other type if the NAT's
>       external side is in a private address domain.
> 
> That's confusing - I think this can be improved by using more precise
> terms in the first sentence (including adding quotes):
> 	 external instead of public ->
> 		 "external IP address" instead of "public IP address"
> 
> -- Section 2
> 
>    The loss of a
>    RTP mapping can only be detected when expected traffic does not
>    arrive.  If a client does not receive data within a few seconds after
>    having received the "200 OK" response to a PLAY request, it may be
>    the result of a middlebox blocking the traffic.
> 
> Are "200 OK" and "PLAY request" sent via RTP?  I don't think so ...
> please clarify.
> 
> -- Section 4
> 
> Add an explanation of what the "Transition:" text discusses for each
> mechanism are about - transition from what to what?  I believe that
> these chunks of text concern transitioning to a (hypothetical, IMHO)
> world in which NATs don't exist.
> 
> -- Section 4.3.4 Disadvantages list
> 
>    o  Assumes that it is possible to de-multiplex between the packets of
>       the media protocol and STUN packets.
> 
> It is possible, although not elegant.  Add a pointer to Section 5.1.2
> of RFC 5764 for this.
> 
> -- Section 5
> 
>    DDoS attacks occur if
>    the attacker fakes the messages in the NAT traversal mechanism to
>    trick the RTSP server into believing that the client's RTP receiver
>    is located on a separate host.
> 
> "a separate host" -> "the host to be attacked".
> 
> -- Section 8
> 
> The second paragraph in this section summarizes the security considerations
> from Section 4.  It ought to be followed by a paragraph that compares/
> contrasts the degree of security risks of the various NAT traversal mechanisms
> to draw some conclusions - e.g., are some of the proposed mechanisms simply
> infeasible/implausible because the security risks are too high?
> 
> idnits 2.13.01 found a few minor concerns with the references:
> 
>   == Outdated reference: A later version (-07) exists of
>      draft-ietf-mmusic-latching-05
> 
>   == Outdated reference: A later version (-21) exists of
>      draft-ietf-mmusic-rtsp-nat-20
> 
>   -- Obsolete informational reference (is this intentional?): RFC 3489
>      (Obsoleted by RFC 5389)
> 
> The final concern deserves attention - it would be a good thing if the
> need to reference to RFC 3489 could be eliminated.  See [J] above for
> one suggested step towards that end.
> 
> --- Selected RFC 5706 Appendix A Q&A for OPS-Dir review ---
> 
> In general, there is a lot of operational considerations material
> (applicable to A.1 questions) in this draft.  Beyond that, management
> considerations (A.2 questions) are generally inapplicable.
> 
> A.1.1.  Has deployment been discussed?
> 
> 	Yes, there is significant good material on deployment considerations.
> 
> A.1.3.  Has the migration path been discussed?
> 
> 	Not much, but discussion of migration is mostly deferrable to the
> 	documentation of the selected NAT traversal mechanism and its
> 	components.  Ease/difficulty of adding the NAT traversal support
> 	could have been an evaluation consideration, but was not used.
> 	On balance, this seems ok.
> 
> A.1.4.  Have the Requirements on other protocols and functional
>        components been discussed?
> 
> 	Yes, the discussion of each NAT traversal mechanism indicates what,
> 	if any changes would be needed to protocols used by that mechanism.
> 
> 	But ... see major issue [2] above on the need for clarification
> 	of the discussion of obsolete/unusable protocol changes/features.
> 
> A.1.9 Is configuration discussed?
> 
> 	Yes, as part of the deployment considerations discussion, and
> 	the desire to avoid complexity of configuration is one of the
> 	evaluation criteria (R4).
> 
> Thanks,
> --David
> ----------------------------------------------------
> David L. Black, Distinguished Engineer
> EMC Corporation, 176 South St., Hopkinton, MA  01748
> +1 (508) 293-7953             FAX: +1 (508) 293-7786
> david.black <at> emc.com        Mobile: +1 (978) 394-7754
> ----------------------------------------------------

Gmane