Re: AD comments on draft-ietf-rmt-pi-norm-revised-08

Magnus,

I have addressed your comments below and posted a new NORM PI draft.  
(version 09)

Some comments on my changes:


Your suggestions were useful in clarifying some areas and I think that  
was quite helpful.

The "source_id" field is, in my opinion, an area where if the IETF  
converges towards any sort of standard approach to end identifiers  
that are independent addressing where a future version of the NORM  
spec could be improved.  Meanwhile, existing NORM deployments have  
used either administratively configured identifiers or identifiers  
based on an IP interface the host has.  The reason for the NormNodeId  
independent of addresses is due to multi-homing, NAT and other  
considerations that some assumption on an address may not meet.  As  
things like Host Identity Protocol (HIP) or other mechanisms are  
defined and have traction I think the spec could be re-visited in this  
specific area.

I added a "floor()" wrapper around the cc_loss calculation below as  
you point out.  Although the roundoff is not significant in any case,  
it is probably a good idea to specify something exactly so that there  
is consistency that might otherwise be confusing if one were to be  
observing the protocol ...

Brian Adamson
[email protected]




On Feb 27, 2009, at 10:48 AM, Magnus Westerlund wrote:

> Hi,
>
> I have reviewed the NORM PI and have some comments that I like to see
> addressed before IETF last call.
>
> 1. Document obsoletes RFC 3940? If yes, include in header, abstract  
> and
> introduction that fact.
>
> 2. Section 4.1:
>
> Sequence number description is a bit cryptic. If I understand it
> correctly each and every norm node has one sequence number space in  
> its
> sender role (if sender), and another in the receiver role (if  
> receiver).
>
> 3. Section 4.1:
>
>   The "source_id" field is a 32-bit value identifying the node that
>   sent the message.  A participant's NORM node identifier (NormNodeId)
>   can be set according to application needs but unique identifiers  
> must
>   be assigned within a single NormSession.  In some cases, use of the
>   host IP address or a hash of it can suffice, but alternative
>   methodologies for assignment and potential collision resolution of
>   node identifiers within a multicast session need to be considered.
>   For example, the "source identifier" mechanism defined in the Real-
>   Time Protocol (RTP) specification [RFC3550] may be applicable to use
>   for NORM node identifiers.  At this point in time, the protocol  
> makes
>   no assumptions about how these unique identifiers are actually
>   assigned.
>
> I think this is awfully vague for being a fully specified protocol on
> the standards track. Doesn't the implementation experience have at  
> least
> one mechanism that can be default to use?
>
> 4. Page 26:
> "Example: EXT_FTI Header Extension Format for "fec_id" =  
> 129"
>
> Use of the wrong symbols in source seems to have produced some  
> escaping.
>
> 5. Page 28:
> "Values of "stream_control_code" that are not
>   understood SHOULD be ignored."
>
>   What can one possibly do if one doesn't understand them? Are there a
> reason to build implementations that doesn't ignore them?
>
> 6. 4.2.3.4:
>
> "If NORM is operated in a private network with
>   congestion control operation disabled, the "NORM_CMD(CC)" message is
>   then used for GRTT measurement only and may optionally be sent less
>   frequently than with congestion control operation."
>
> I think "private network" isn't the right naming of what the network
> where one can turn off congestion control. "operated in a network  
> where
> resources are explicitly dedicated to the NORM session and therefore
> congestion control operation is disabled ..."
>
> 7. 4.2.3.5:
>
> "cc_loss" = decimal_loss_fraction * 65535.0
>
> Does the rounding of this value matter when converting to the 16-bit
> value. Most platforms that just strips the value would be equivalent  
> to
> a floor. Does it matter if ceiling or round would be used instead?
>
> 8. Section 5.1:
>
> Congestion control operation SHALL be
>   observed at all times when operating in the general Internet.
>
>   I would like to strengthen this statement to say: at all times when
> not operating using dedicated resources, like in the general Internet.
>
> 9. Section 5.5.2:
>
>   This congestion control scheme is REQUIRED for operation
>   within the general Internet unless the NORM implementation is  
> adapted
>   to use another IETF-sanctioned reliable multicast congestion control
>   mechanism (e.g., PGMCC [PgmccPaper]).
>
> The above sentence implies that PGMCC is an approved RFC document. I
> would propose to remove the complete parenthesis.
>
> 10. Section 5.5.2:
>
> The details of PLR
>   selection are not discussed in this document.
>
> I think this and the paragraph can be misleading to that there are no
> support to build the CLR + PLR list. The protocol does have a  
> mechanism
> for receiver to raise their hand and say: Hey, I may belong on this  
> list.
>
>
> 11. Section 6:
>
> The same security considerations that apply to the NORM, TFMCC, and
>   FEC Building Blocks also apply to the NORM protocol.
>
>   Please include reference indicators here.
>
>
> 12. Section 6.1:
>
> The current RTP spec is RFC 3550 and not RFC 1889.
>
> 13. Section 7.1 & 11.1
>
> RFC 2434 has been replace by RFC 5226
>
> 14. Section 11.1 and 1
>
>   This document is a product of the IETF RMT WG and follows the
>   guidelines provided in [RFC3269].
>
> This is in my view an informative reference. So please move the
> reference to the informative part.
>
>
> 15. ID Nits that needs to be fixed:
>
>  == The document seems to lack the recommended RFC 2119 boilerplate,
> even if
>     it appears to use RFC 2119 keywords -- however, there's a  
> paragraph
> with
>     a matching beginning. Boilerplate error?
>
>     (The document does seem to have the reference to RFC 2119 which  
> the
>     ID-Checklist requires).
>  == Using lowercase 'not' together with uppercase 'MUST', 'SHALL',
> 'SHOULD',
>     or 'RECOMMENDED' is not an accepted usage according to RFC 2119.
> Please
>     use uppercase 'NOT' together with RFC 2119 keywords (if that is
> what you
>     mean).
>
>     Found 'SHALL not' in this paragraph:
>
>     The "NORM_CMD(SQUELCH)" command is transmitted in response to
>     outdated or invalid "NORM_NACK" content received by the sender.  
> Invalid
>     "NORM_NACK" content consists of repair requests for NormObjects  
> for
> which
>     the sender is unable or unwilling to provide repair.  This  
> includes
>     repair requests for outdated objects, aborted objects, or those  
> objects
>     which the sender previously transmitted marked with the
>     "NORM_FLAG_UNRELIABLE" flag.  This command indicates to  
> receivers what
>     content is available for repair, thus serving as a description  
> of the
>     sender's current "repair window".  Receivers SHALL not generate  
> repair
>     requests for content identified as invalid by a  
> "NORM_CMD(SQUELCH)".
>
> Cheers
>
> Magnus Westerlund
>
> IETF Transport Area Director & TSVWG Chair
> ----------------------------------------------------------------------
> 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: [email protected]
> ----------------------------------------------------------------------
> _______________________________________________
> Rmt mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/rmt
>