Thanks you for your careful review and for your comments. We have looked into your comments, and we try to provide answers inline within your original email included below. We will update the draft according to our answers below, please let us know in case the proposed resolutions to your comments is not to your satisfaction as well as, if possible, a quick resolution. Best regards, The authors, Ghyslain Pelletier Kristofer Sandlund ----Original Message---- From: Elwyn Davies [mailto:elwynd@xxxxxxxxxxxxxx] Sent: den 7 mars 2008 19:55 > Document: draft-ietf-rohc-rfc3095bis-rohcv2-profiles-05 > Comments: > s1: It would be worth a sentence to remind readers without deep > knowledge of ROHC that the reason that the document does not 'update > RFC 3095, etc' is because the protocol negotiates the available > profiles > between compression endpoints - so the extra profiles defined here > just > add to the available set. [AUTHORS] We propose to not make any change to the current text. RFC4995 in section 5.1.2 defines the channel parameter "PROFILES" where the workings of the profile identification mechanism are clearly expressed; section 8 also defines some guidance on how to assign profile identifiers in ROHC specifications. In short, ROHC profiles use identifiers of the format "0xYYXX", while common parts of (framework) packet formats use only the "XX" part. Therefore, the setup of a ROHC channel cannot result in a set of profiles that include two profiles having the same value for "XX". When the channel is being setup, if it is the case, the profile that has the highest value for "YY" then has precedence and shall be used in the final configuration of the channel. draft-rohcv2 states that the ROHCv2 profiles update corresponding profiles in RFC3095; it also clearly assigns new profile identifiers to each of the profile defined in the document directly under this text, where each identifier defined has "YY" = "01". More specifically, we motivate not changing the current text mainly because our view is that knowledge of RFC4995 is a necessary prerequisite to draft-rohcv2 (and to any other ROHC profile specification). We also believe that there is no reason to mention whether a specification updates another one, unless it actually does so. As a side note for clarity, it is incorrect to state that the ROHC "protocol negotiate the available profiles"; the framework only places a requirement that a number of parameters, including the set of available ROHC profiles, be consistent between two endpoints of a ROHC channel. Whether this is negotiated, statically provisioned or achieved in another way is actually outside the scope of the protocol. However, this being said, we could still propose a modified text -- although we do not believe this would improve the current draft and we have struggled somewhat with its formulation: OLD: This document defines an updated version for each of the above mentioned profiles, and its definition is based on the specification of the ROHC framework as found in [RFC4995]. NEW: This document defines a set of profiles called ROHCv2 profiles. Each ROHCv2 profile is defined with its own profile identifier. Identifiers are assigned to conceptually represent the ROHCv2 profile as a variant of the profile that can compress similar header combination(s) from the list above. The definition of the ROHCv2 profiles complies with the specification of the ROHC framework as found in [RFC4995]. Note: Please let us know which way forward is according to your preference. By default, we will not make the modification. Would you not be satisfied with any of the proposed alternatives, please provide a text proposal that would resolve your comment. > s6.3.x/s6.8.2.1: It would be easier for the reader (and more robust) > to > use the profile names rather than the expected hexadecimal values when > referring to profiles here and anywhere else apart from the > definitions. Also there is some inconsistency as to whether the > profile > names should be capitalized or not. Please choose one version. [AUTHORS] We propose to not make any change to the current text. We believe that the draft is consistent in its usage of profile names and their corresponding hexadecimal values. Basically, we deliberately avoid to use profile names and prefer to use the hexadecimal values for clarity, precision and conciseness (e.g. the draft uses profile 0x0101 instead of ROHCv2 RTP). Wrt capitalization, names in small letters are a consequence from the formal notation in the packet format section. The ROHC-FN (RFC4997) is case-sensitive and capital letters are normally used only for keywords within the formal notation itself. In the specification text (plain english part), some of the encoding method names are still referred there, and these cannot be capitalized otherwise it would create confusion. In case we misunderstood your comment, please provide more clear indications on this issue. We have reviewed the document and could not find inconsistencies from our perspective. > s6.6.8, next to last para: I believe the 'optional' should be an > 'OPTIONAL'. > s6.6.9, last para: -- ditto -- [AUTHORS] We agree to this and will make the change. > s6.6.13: Given that the protocol is supposed to tolerate some > reordering, I think some words about how to handle sequentially early > packets containing updates to list specifications wuld be useful. > Implementations might have to ensure that they can cope with the pre- > and post-update specifications for a short period if I understand > correctly. [AUTHORS] We propose to not make any change to the current text. We motivate this from the fact that this is handled in draft-rohcv2 by section 5.1.2, which in turn refers to section 5.1.1 (Optimistic Approach) for seldom changing fields. In other words, sending updates to lists wrt reordering is a typical topic that is handled by the recommendations about how to implement the optmistic approach in section 5.1.1, being no different than any other update to non-sequentially (e.g. lsb-encoded) changing fields. > s6.9.1: The diagrams of feedback formats are inconsistent (some have > bit > numbers, some don't). Also values should be specified in the text as > well as as labels in the diagrams, and the encosing of the fields > needs > to be specified (unsigned ints I guess). [AUTHORS] We agree that the diagrams on the feedback options are not consistent. We also agree that the encoding of the clock resolution should be specified, but we do not see any other field for which this is needed. We will fix this. > Appendices A.1 and A.2: The Type of Service/Traffic Class fields are > also known as DSCP (DiffServ Code Points) as of six or seven years > ago. > With the advent of Early Congetion Notification which uses bits in > these > octets, the values in these fields may not be as 'rarely changing' as > would have been expected previously. It is also possible that some of > the DiffServ PHBs might lead to more variable values in these fields > although this is probably less likely in regions where ROHC is in use. > Should this be taken into account? [AUTHORS] We propose to not make any change to the current text. The motivations are that how fields are classified only matters wrt to helping choosing a compression strategy for the field. The classification should only match the most expected case, otherwise a slightly less efficient compression could occur. Wrt to this, the only thing that matters is that the compression protocol is always transparent, which ROHC must be as a requirement from the framework and from general IETF practices. As our understanding is that ECN codepoints are expected to be used only for TCP traffic -- we are not aware of any specifications/deployments for ECN and rate control for RTP applications as of this writing -- and because ROHCv2 does not explicitely compress TCP traffic (RFC4996 defines ROHC compression for TCP), we see no reason to optimize the compression of the ECN codepoints or to modify this part of the text to further clarify expected behavior. > Editorial: > > General: use of lsb or LSB. The document is extremely inconsistent. > General: Capitalization of (Most) Words in Section Headings needs > Attention. [AUTHORS] Wrt to capitalization, as explained earlier we believe that the document is consistent wrt to the plain english text part of the specifications, wrt the formal notation part and wrt the "mixed" parts. If you still disagree, please provide specific examples in light of the answers in this mail. We agree wrt section headers, we will fix this. > s5, para 1: s/concepts relates/concepts relate/ [AUTHORS] ACK > > s5.1.3, last para: s/to determine/for determining/ [AUTHORS] ACK > s5.2, para 2: s/to always verify the outcome of/for verifying the > outcome of every/ [AUTHORS] ACK > s6.2, para 3: s/increasing/to increase/ [AUTHORS] ACK > s6.6.8, para 2: s/notation ./notation./ [AUTHORS] ACK > s6.8.2.1: Extra blank line needed after first bullet for consistency. [AUTHORS] ACK blank line needed after first bullet for consistency. _______________________________________________ IETF mailing list IETF@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf