Hi Gorry, Thanks -- see inline... Tom P. > -----Original Message----- > From: Gorry Fairhurst [mailto:gorry@xxxxxxxxxxxxxx] > Sent: Tuesday, January 15, 2008 12:07 PM > To: ''dccp' working group' > Cc: Phelan, Tom > Subject: Comments on draft-ietf-dccp-dtls-04.txt > > > I have the following comments, which I'd like to be taken into > consideration during this WGLC: > > There are two issues I'd like clarified: > > --- > Page 7, section 3.5, para 2. > "Alternatively, DTLS over DCCP implemenations MAY choose to use its own > PMTU Discovery"... > - The recent comments from Pasi, show a different interpretation of this > to what I had in mind, so I'd like clarification on this. > - If DTLS wants to probe, just to be absolutely sure the path supports > it, that's fine with DCCP. But to me, the probes are not really an > ALTERNATIVE to DCCP doing this, but DCCP does not provide a way to send > any packet it likes with a size bigger than MPS (except where the API > provides optional fragmentation, which is not what is intended here). > [Tom P.] I agree with this overall. Just don't forget what comes right after that quote saying DTLS MUST NOT use a value greater than DCCP's. > <see related mail thread> > > --- > Page 8, section 3.6, first para. > - Following the WG meeting discussions at the last IETF meeting, it > seems we need to consider the requirement that applications using > DTLS/DCCP and ones not using DTLS/DCCP "MUST use different Service > Codes". It was suggested that this could be too strong, and noted that > this is NOT an interoperability issue, and not one that the IETF could > easily enforce. > - I wonder if it is wiser to recommend that they "SHOULD register and > use different Service Codes". > - To me, the current text does seem to describe the rationale that would > support this recommendation (i.e. say why we have written this). [Tom P.] Yes, I feel better with this as a SHOULD. > --- > Page 8, section 3.7, final para > I question whether this is an issue of "feeling" - if it needs a > different Service Code, they should register one and use it: > /If the > application developers feel that the new version of DTLS provides > ^^^^ > significant new capabilities to the application that will change the > behavior of middleboxes, they MAY use a new Service Code./ > I suggest: > /If a new version of DTLS provides > significant new capabilities to the application that will change the > behavior of middleboxes, an application developer MAY register a new > Service Code./ > --- > [Tom P.] I agree that the new text is better. > ----------------------------------------------------------------------- > > Editorial: > --- > It seems that you have chosen CCIDn (e.g. CCID3) to denote CCID 3, other > RFCs have used a space or hyphen (if they wish to directly link the > number and CCID). Would one of these other forms be acceptable? [Tom P.] The RFCs seem to use CCID X consistently, I'll change. > --- > page 4, section 3.2, final para, line 5 > /Server implementations/ > ^^^^^^^ > - This is not really a feature negotiation or call-setu-function, so it > would be better to omit the word server. To me this applies equally to > clients and servers. [Tom P.] If I've found the place you're talking about, the full sentence says "For example, DCCP Server implementations are free to discard Application Data received in DCCP-Request packets". Only the server side can received DCCP-Request packets. I think it's clear that "Server" shouldn't be capitalized. The sentences meaning would probably still be clear without "server" too. > --- > page 7, section 3.5 > - Please change: /CMPS/CCMPS/ > [Tom P.] Oops! --- > Page 8, section 3.7 > /to this document, it is assumed/ > ^^ > - I think it would be clearer to use "which" instead of "it" to remove > possible amibiguity that this is speaking of the document itself. > [Tom P.] Well, "it" *is* meant to refer to the document itself -- "in the absence of a revision to this document, this document is assumed to apply to all future versions of DTLS" -- a little clumsy, but at least it seems to be unambiguous. ---- > Page 8, section 3.7, final para > - It would be helpful to remind readers that DTLS itself identifies the > version, before proceding with the SC discussion: > Please add: > "The DTLS version value [RFC4347] identifies the version of DTLS that is > in use. > [Tom P.] The second sentence of 3.7 is roughly equivalent to that. Do we really need to say it again? ---- > I note this I-D does not include the optional section on acknowledgments > section. > ---- [Tom P.] Yes, now that I've had some feedback that's good idea, thanks.
