[Gen-art] review of draft-iana-rfc3330bis-06.txt
I have been selected as the General Area Review Team (Gen-ART) reviewer for this draft (for background on Gen-ART, please see http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html). Please resolve these comments along with any other Last Call comments you may receive. Document: draft-iana-rfc3330bis-06.txt Reviewer: Francis Dupont Review Date: 2009-04-03 IETF LC End Date: 2009-04-18 IESG Telechat date: unknown Summary: Ready Major issues: None Minor issues: None Nits/editorial comments: I have two concerns about the Abstract: - the first sentence This document obsoletes RFC 3330. should be removed before the publication as an RFC - the last sentence has an explicit reference to RFC 5156, this could be considered as forbidden in an Abstract, I propose to change it into: ... are described in another document (RFC 5156). In authors' addresses: United States - United States of America (there is an incredible amount of countries with a full name translating into united states in English :-). Regards francis.dup...@fdupont.fr ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
Re: [Gen-art] Gen-ART review of draft-ietf-kitten-gssapi-channel-bindings-06.txt
On Mon, Apr 06, 2009 at 10:35:23AM -0500, Nicolas Williams wrote: On Sun, Apr 05, 2009 at 10:30:21AM +1200, Brian E Carpenter wrote: Summary: Almost ready; needs one clarification. Comments: I was expecting the sentence quoted below to be updated following Nico's comments on my Last Call comment. I think the new text would be Where the language binding of the GSS-API model's channel bindings is as single OCTET STRINGs (or the language's equivalent), then the implementation SHOULD assume that the given bindings correspond only to the application-data field of GSS-CHANNEL-BINDINGS as shown above. Oops, sorry I missed that edit. I'll submit a revised I-D shortly -- I'll s/is as/is as a/. Er, no, I did update that. I replaced the above with: Where a language binding of the GSS-API models channel bindings as OCTET STRINGs (or the language's equivalent), then the implementation MUST assume that the given bindings correspond only to the application-data field of GSS-CHANNEL-BINDINGS as shown above, rather than some encoding of GSS-CHANNEL-BINDINGS. I think that's clearer. Nico -- ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] about draft-ietf-ccamp-path-key-ero-04.txt
I reviewed the version 03, I keep the Ready summary. Regards francis.dup...@fdupont.fr PS: the spelling error in 7.1 page 12 only changed, correct spelling (checked twice as it seems really hard to type :-) is: signaling (leave it to the RFC Editor...) ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
Re: [Gen-art] Gen-ART LC review of draft-ietf-lemonade-streaming-10
Just to let people know, version 10 of this draft addresses all my questions from my -09 review. Ready to publish as Informational. Thanks, Spencer I have been selected as the General Area Review Team (Gen-ART) reviewer for this draft (for background on Gen-ART, please see http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html). Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-lemonade-streaming-09 Reviewer: Spencer Dawkins Review Date: 2009-03-06 IETF LC End Date: 2009-03-12 IESG Telechat date: (not known) Summary: Almost ready for publication as Informational. A couple of nits (forwarded for the editor, not part of Gen-ART reviews), and a couple of minor questions. Comments: 1. Introduction Email clients on resource and/or network constrained devices, such as mobile phones, may have difficulties in retrieving and/or storing large attachments received in a message. For example, on a poor network link, the latency required to download the entire attachment Spencer (nit): s/attachment/attachment before displaying any of it/, perhaps? The sentence seems to say the user won't download the entire attachment under any conditions, but that's probably not what it should say... may not be acceptable to the user. Conversely, even on a high-speed network, the device may not have enough storage space to secure the attachment once retrieved. 3.1. Overview of Mechanism The proposed mechanism has the following steps: 1. Client determines from MIME headers of a particular message that a particular message part (attachment) should be streamed to the user. Note that no assumptions are made about how/when/if the client contacts the user of the client about this decision. User input MAY be required in order to initiate the proposed mechanism. Spencer (minor): this MAY doesn't smell 2119 to me... 3.2. Media Server Discovery There is also a scenario where media server discovery would improve the security of the streaming mechanism, by avoiding the use of completely anonymous URLs. For example, the client could discover a media server address that was an authorised user of the IMAP server for streaming purposes, which would allow the client to generate a URL, which was secure in that it could *only* be accessed by an entity that is trusted by the IMAP Server to retrieve content. The issue of trust in media servers is discussed more fully in Section 4 Spencer (nit): missing period after 4. Example values of the /shared/mediaServers METADATA entry: sip:i...@ms.example.net:5060:stream;sip:annc@ ms1.example.net:5060;sips:i...@ms2.example.net:5061 sip:i...@192.0.2.40:5060;sip:192.0.2.41:5060;sips:annc@ 192.0.2.42:5060:stream Spencer (minor): Hmm. The paragraph that talked about line wrapping in section 2 was specifically about S: and C:, and that doesn't apply here. Is this clear enough for the target reader? At a minimum, I see people indenting continuation lines in other specs... 3.7. Client Use of the Media Server MSCML IVR Service Since the playcollect request is used purely for its VCR capabilities, there is no need for the media server to perform DTMF collection, therefore the playcollect attributes firstdigittimer, interdigittimer and extradigittimer SHOULD all be set to 0ms, which will have the effect of causing digit collection to cease immediately the media has finished playing. Spencer (minor): immediately the is missing a word... if I could guess which word, this would be a nit. 3.8. Media Server Use of IMAP Server If the media server is configured as an authorized user of the IMAP server, it SHOULD authenticate to the IMAP server using the credentials for that user. This document does not go into the details of IMAP authentication, but the authentication SHOULD NOT use the LOGIN command over a non-encrypted communication path. Spencer (minor, because I'm not your security reviewer): I'm struggling why this last statement is SHOULD NOT with no qualifications... if you tell me that this is normal practice in the e-mail community, I'll be quiet, but this would worry me if I saw it happening. 4. Security Considerations o However, since the media server will retrieve content from an IMAP server on the users behalf, the issue of security between the IMAP Spencer (nit): s/users/user's/ server and the media server also needs to be considered. A client has no way of determining (programatically at least) the security of the exchanges between the media server and the IMAP server. However, it can determine, using the stream token that is part of the media server discovery mechanism described in Section 3.2, that the media server has a pre-existing authentication relationship with the IMAP server for the purposes of retrieving content using IMAP URLs. The IMAP
Re: [Gen-art] Gen-ART review of draft-ietf-kitten-gssapi-channel-bindings-06.txt
Nico, The paragraph is identical in the -05 and -06 drafts, so no, actually you didn't change anything after my review. I still find the text a little unclear. I don't feel strongly about this; Russ has just logged it as a comment, so it's up to you and Tim whether to change anything. Brian On 2009-04-07 03:42, Nicolas Williams wrote: On Mon, Apr 06, 2009 at 10:35:23AM -0500, Nicolas Williams wrote: On Sun, Apr 05, 2009 at 10:30:21AM +1200, Brian E Carpenter wrote: Summary: Almost ready; needs one clarification. Comments: I was expecting the sentence quoted below to be updated following Nico's comments on my Last Call comment. I think the new text would be Where the language binding of the GSS-API model's channel bindings is as single OCTET STRINGs (or the language's equivalent), then the implementation SHOULD assume that the given bindings correspond only to the application-data field of GSS-CHANNEL-BINDINGS as shown above. Oops, sorry I missed that edit. I'll submit a revised I-D shortly -- I'll s/is as/is as a/. Er, no, I did update that. I replaced the above with: Where a language binding of the GSS-API models channel bindings as OCTET STRINGs (or the language's equivalent), then the implementation MUST assume that the given bindings correspond only to the application-data field of GSS-CHANNEL-BINDINGS as shown above, rather than some encoding of GSS-CHANNEL-BINDINGS. I think that's clearer. Nico ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
Re: [Gen-art] Gen-ART review of draft-ietf-kitten-gssapi-channel-bindings-06.txt
On Tue, Apr 07, 2009 at 09:09:03AM +1200, Brian E Carpenter wrote: The paragraph is identical in the -05 and -06 drafts, so no, actually you didn't change anything after my review. It differs rather slightly. I guess the current form still strikes me as clear so I didn't realize that I hadn't really changed it. I'll re-work it. ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
