Subject: [Gen-art] review of draft-ietf-mmusic-rtsp-nat-21.txt

From: Francis Dupont <[email-masked]>
Date: Mon, 23 Jun 2014 15:44:24 +0200

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-mmusic-rtsp-nat-21.txt
Reviewer: Francis Dupont
Review Date: 20140620
IETF LC End Date: 20140620
IESG Telechat date: unknown

Summary: Ready

Major issues: None

Minor issues: None

(a metacomment anyway: with the arrival of IPv6 we should not spend
too much time/effort on NAT traversal...)

Nits/editorial comments:
 - Abstract page 1 (and many other places): signalling -> signaling

 - ToC page 3 and 12 page 30: Acknowledgements -> Acknowledgments

 - 1 page 3: (style) too many "number" in
   There have been a number of suggested ways of resolving the NAT-
   traversal of media for RTSP of which a large number are already used
   in implementations.

 - 3 page 5 (4) (and 6.10 page 20, 9 page 27): e.g. -> e.g.,

 - 4.1 page 6: (style) must be -> has to be

 - 4.2 page 9 (connection-address): (ambiguous wording)
      ...  An IP address
      SHOULD be used, but an FQDN MAY be used in place of an IP address.

 - 4.2 page 10 (extension-att-*): delimeter -> delimiter

 - 6.3 page 16 (and 6.13 pages 22 and 23):
    (uniform use of a space after ';')
     RTP/AVP/TCP;unicast;interleaved=0-1 ->
     RTP/AVP/TCP; unicast; interleaved=0-1   

 - 6.7 pages 18 and 19: Succeded -> Succeeded

 - 7.1 page 23: will need to be run -> will be run

 - 9 page 26: i.e. -> i.e.,

Regards

[email-masked]

---

From: "Jeff Goldberg (jgoldber)" <[email-masked]>
Date: Tue, 24 Jun 2014 10:25:31 +0000

Dear Francis,
I’ve done the changes, but I need some more information:

>  4.2 page 9 (connection-address): (ambiguous wording)
>      ...  An IP address

[JIG] I’m not getting the ambiguity. Unusually, we deliberately _are_ recommending using an IP address over an FQDN but allowing both, and the reasoning for preferring an IP address is self evident from additional complexity in the succeeding sentences. Can kindly you help me here? 

Thanks

Jeff

P.S. Some inline comments:

> - Abstract page 1 (and many other places): signalling -> signaling

[JIG] A British English to US English problem (I’m British…). I caught another of these and fixed it in the draft.
> - 3 page 5 (4) (and 6.10 page 20, 9 page 27): e.g. -> e.g.,

[JIG] This is my first IETF RFC so I don’t know the “house style” but from a British English viewpoint, you would not put a comma ever in front of “e.g.” in these cases. Nevertheless the changes have been made in the new draft.

>      SHOULD be used, but an FQDN MAY be used in place of an IP address.

[JIG] I’m not getting the ambiguity. Unusually, we deliberately are recommending using an IP address over an FQDN but allowing both, and the reasoning for preferring an IP address is self evident from additional complexity in the succeeding sentences. Can kindly you help me here? 

> - 6.7 pages 18 and 19: Succeded -> Succeded

[JIG] And this should be: Succeded -> Succeeded (notice the “ee”) and has been changed
> - 9 page 26: i.e. -> i.e.,

This is my first IETF RFC so I don’t know the “house style” but from a British English viewpoint, you would not put a comma ever in front of “i.e.” in this case. Nevertheless the change has been made in the new draft.

---

From: Francis Dupont <[email-masked]>
Date: Wed, 25 Jun 2014 14:20:11 +0200

In your previous mail you wrote:

>  Dear Francis,
>  I've done the changes, but I need some more information:
>  
> [JIG] I'm not getting the ambiguity.

=> IMHO "A SHOULD be used, but B MAY be used" without a complete list
of cases where B SHOULD be used (i.e., the exceptions) is inherently
ambiguous.

>  Unusually, we deliberately _are_ recommending using an IP address
>  over an FQDN but allowing both

=> I understand the idea but IMHO the wording is not the right one
(i.e., SHOULD is too strong).

>  and the reasoning for preferring an IP address is self
>  evident from additional complexity in the succeeding sentences.

=> the succeeding sentences are about support (where SHOULD+MAY
don't conflict).

Thanks

PS: there are (at least) two ways to solve this:
 - to ignore my comment (I put it into editorial comments to allow this
  solution, the other choice was to make a minor point with a high
  probability to see a DISCUSS about the point :-).
 - to get some advice from the list as I shall be very surprised it is
  the first case we have a conflict for a SHOULD+MAY about use.

---

From: "Jeff Goldberg (jgoldber)" <[email-masked]>
Date: Fri, 27 Jun 2014 09:54:13 +0000

Dear Francis,
I’ve discussed this with a few people at Cisco who have done RFCs and we’ve come to the conclusion that SHOULD and MAY can be removed. The sentence now reads:

An IP address is preferred for simplicity but both an IP Address and FQDN can be used

As you can tell, this is my first draft that has progressed at all, and I thank you kindly for helping a “newbie”

I’m going to upload a new version with the fixes.

Jeff