Re: [Rmt] AD evaluation comments on draft-ietf-rmt-flute-revised-06

[Magnus Westerlund <magnus.westerlund at ericsson.com>]

Thanks Toni,

I am back from my vacation and lets dig into the remaining issues. I
have reviewed your updates and responses to my AD comments. I CC the RMT
mailing list to keep them in the loop and to enable others to comment.

I removed the issues I see having been resolved.


toni.paila at nokia.com skrev:
>> 2. I have basically the same comment on this document as on 
>> ALC PI about mandatory to implement security solutions.
>>
> 
> [Toni] Unfortunately I have not followed that closely the review on ALC. Could you please state the needed change you want to see in FLUTE RFC?

Okay, the general issue comes from BCP 61 (RFC 3365) and I think the
sentence from the end of section 6 is the most relevant:

   The solution is that we MUST implement strong security in all
   protocols to provide for the all too frequent day when the protocol
   comes into widespread use in the global Internet.

To achieve this and have interoperability also in the strong security
mechanism the ground rule is to mandate implementation of at least one
mechanism, cipher suite, etc to achieve that interoperability.

The current security consideration section does a great job of
discussing the threats and possible solution. But it doesn't mandate
which solutions MUST be implemented.

So the question to you and the WG is can we do this for FLUTE? I know
this is not straight forward and certain deployments has different needs
and use of security.


> 
>> 4. Section 1. As the ALC PI isn't suitable for general 
>> deployment using unicast, flute can't really either. The 
>> congestion control is the issue.
>>
> 
> [Toni] Reviewing section 1 and sub sections of section 1 I think this item is stated.
> 
> Especially:
>   "FLUTE can be used with both multicast and unicast delivery, but it's
>    primary application is for unidirectional multicast file delivery.
>    FLUTE requires connectivity between a sender and receivers but does
>    not require connectivity from receivers to a sender.  FLUTE
>    inherently works with all types of networks, including LANs, WANs,
>    Intranets, the Internet, asymmetric networks, wireless networks, and
>    satellite networks.
> 
>    FLUTE is compatible with both IPv4 or IPv6 as no part of the packet
>    is IP version specific.  FLUTE works with both multicast models: Any-
>    Source Multicast (ASM) [15] and the Source-Specific Multicast (SSM)
>    [16].
> 
>    FLUTE is applicable for both Internet use, with a suitable congestion
>    control building block, and provisioned/controlled systems, such as
>    delivery over wireless broadcast radio systems."
> 
> Do you think I should change section 1 somehow? If so, how?

In some sense the information are there, but it is not made particularly
clear that unicast delivery over Internet is lacking a good congestion
control mechanism to my knowledge. Currently the only thing that I can
think of is using Webrc or at least reception monitoring and then a
separate control protocol to stop the streams.

In general the massive scaling properties are colliding with unicast.

Thus could we make this clear in Section 1.1.4?



> 
>> 5. Section 3.3, there is a reference to the NTP time format. 
>> NTP v4 has been to IESG but are not approved yet. Are there a 
>> point of actually referencing the clarified formats in that 
>> doc? That also have a clarified discussion about epochs that 
>> helps handling the wrap around.
>>
> 
> [Toni] How would you change the current statement "Handling of wraparound of the 32 bit time is outside the scope of NTP and FLUTE."
> I cannot come up with any other more accurate statement for this part of the spec.

Well, the new NTP spec does discuss epochs. And if you have a local
clock, then you can actually know which epoch it currently are and apply
that. That seems the most reasonable handling of this wrap around.

Maybe an informal pointer about the handling of epoch to
draft-ietf-ntp-ntpv4-proto. Section 6 seems to be the main interesting one.


> 
>> 6. Section 3.4.1:
>>   Mandatory receiver behavior for handling FDT Instance
>>   ID wraparound and other special situations (for example, missing FDT
>>   Instance IDs resulting in larger increments than one) is outside the
>>   scope of this specification and left to individual 
>> implementations of
>>   FLUTE.
>>
>> Why isn't this specified. Seem to be important for interoperable usage.
>> Seems to be a fine thing to gloss over in an experimental, but 
>> not in a proposed standard.
>>
> 
> [Toni] The text states that what actions the special situation causes in the receiver is up to receiver. In a same way your web browser will typically show a different error message than my trying to access http://ww.w3.org. I see one valid implementation trying to recover from situation by staying longer in the session and trying to deduce what happened. Meanwhile I see another implementation possibly using out of band methods (if available) for the same. In other words, error recovery or concealement or similar is not in the scope of the spec. 

Hmm, I will let it slide. Let see if anyone else in IESG bites on this,
clearly not impossible. As it from my perspective looks like where error
conditions could be avoided by specifying the correct behavior.

> 
>> 7. Section 3.4.2:
>>
>> Why is only HTTP URLs valid in the location header? In 
>> addition why was HTTP URLs used? There is after all an 
>> explicit transport mechanism implied by that. Some 
>> clarification on that relation would be good.
>>
> 
> [Toni] At the time of design it was found that "Content-Location" serves the purpose best. I see no problem allowing any generic URL. Would you be so kind and provide me normative reference for generic URL? Would http://www.rfc-editor.org/rfc/std/std66.txt do?
> 

Actually by referencing HTTP (RFC 2616) you actually get that generic
URI are allowed in the header. So from a syntax perspective this appears
to be fine. So actually I might have misinterpreted the spec myself here.

I still find the relation between the URI space used in the
Content-Location header and FLUTE a bit unclear. I wished this was clear
explained, but I will not demand that you improve this.

> 
>> 10. Section 6:
>>
>> Shouldn't this text discuss the need for configuring the 
>> congestion control mechanism also? The security parameters 
>> needs discussion also.
>>
> 
> [Toni] The congestion control parameters to be used depend on the congestion control block to be used. Same goes for security. I suggest adding two bullets in the list of non-exhaustive list of optional items:
>  * Definition and configuration of congestion control mechanism for the session
>  * Security parameters relevant for the session
>  
> Is this OK?
> 

I think this is a good addition to the text.

However, the implementation of WEBRC is mandated by ALC PI which FLUTE
depends on. I guess this means that we might have to get the
mehta-flute-sdp draft back from the RFC-editor to make sure that
congestion control and the necessary security parameters are included in
the FLUTE SDP solution.


>> 11. Section 8.2: Chairs, have the update of the media type 
>> registrations been reviewed on the ietf-types list?
>>
> 
> [Toni] Any progress report from the Chairs on this item?

I don't think this new version has been sent to the ietf-types list for
review. Chairs, please do that as soon as

> 
>> 12. Section 8.2: The template hasn't been updated. The change 
>> controller is a split item and should be saying "IETF".
>>
> 
> [Toni] Would the right line be as follows: "   Author/Change controller: IETF"

"Change controller: IETF" would be correct. It is allowed to split this
line into two items:

Author: Draft authors names
Change controller: IETF

> 
>> 13. Section 8.3.1: It seems to be some confusion about the 
>> usage of URN for purpose of describing where the name spaces 
>> are. I think this needs to be clarified. Can the authors and 
>> the chairs please try to resolve this with the IANA?
>>
> 
> [Toni] I will contact IANA.

Good, please add the chairs and me into the loop.

> 
>> 14. Section 12.2:
>>
>> Are really reference 17 and 18 informative. You are binding 
>> them for a particular usage.
>>
> 
> [Toni] I quess the same comment would apply to [12], also. My point is that [12], [17] and [18] define the compression algorithms that are among the ones which have reserved numbers. The spec does not mandate to implement any of references [12], [17] or [18]. While those specs are indeed associated to certain numbers, I cannot make these Normative references as RFCs 1950 and 1952 are Informative. Hence I kept references [12], [17] and [18] Informative (Note, due to changes in references, these have been renumbered. The references are for GZIP, ZLIB and DEFLATE)	.
> 

Anything that are in another spec that are needed for implementing this
one is an normative specification, indepently if the functionality is
mandated or optional. So please make the normative.

The fact that they are downrefs does not prevent them from being used as
normative references if they are appropriate. In this case 1950 and 1951
clearly are.

I noted at least one reference in this form "RFC 3450 [2]" where the
reference is the revised drafts but using the old RFC numbers. Please
look into this.


There are still issues that needs fixing in my view.

Cheers

Magnus Westerlund

IETF Transport Area Director
----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund at ericsson.com
----------------------------------------------------------------------