[Gen-art] Gen-ART review of draft-ietf-enum-iax-05.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-ietf-enum-iax-05.txt Reviewer: Miguel Garcia Review Date: 09-June-2009 IETF LC End Date: 09-June-2009 Summary: The document is ready for publication as an Informational RFC. Nits/editorial comments: - Section 2. There is a reference to the "associated URI scheme", which points to http://www.iana.org/assignments/uri-schemes/prov/iax It seems that the address is now redirected to http://www.iana.org/assignments/uri-schemes.html I guess one should be careful with this URIs, which can easily change. Perhaps, instead of a reference to an HTTP URI, there should be a reference to draft-guy-iax-05, which seems to be RFC that registers the IAX URI. /Miguel -- Miguel A. Garcia +34-91-339-3608 Ericsson Spain smime.p7s Description: S/MIME Cryptographic Signature ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
Re: [Gen-art] Review: draft-ietf-ntp-autokey-05.txt
Joel, Thanks for the review. At this point, I will not have time to look at these comments until later this week or possibly early next week. When I do, I will provide responses to your comments. Thanks, Brian Joel M. Halpern wrote: 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-ntp-autokey-05.txt Network Time Protocol Version 4 Autokey Specification Reviewer: Joel M. Halpern Review Date: 5-June-2009 IETF LC End Date: 12-June-2009 IESG Telechat date: N/A Summary: While nearly ready for publication as an Informational RFC, this document has some issues that need to be addressed before publication. The issues are described by priority below. Major issues: There appears to be some confusion in the protocol description as to which field actually tells you what message you are handling, and which field tells you that this is NTP Autokey. In teh text in section 10, it says that the "Field Type" field is set to 2, and represents a version number. Further, it says that the 6-bit Code field specifies the request or response. Unfortunately, all of the subsections of section 10 carefully and consistently refer to having different "Field Type" values, not different Code values. Section 4 of this document is explicit that MD5 is the (singular) hash algorithm for generating message signatures and autokeys. I was concerned about lack of algorithm agility. Section 11.1 however includes a 16 bit Digest / Signature NID. 1) There is no description of how this is used / negotiated 2) There is no explanation of the relationship between this and the earlier assertion of MD5 3) While the text mentions that this is defined in "the OpenSSL library", there is no reference, and particularly no reference to any documentation to see what values are defined. Since this ought to be implementable by someone who does not live in the OpenSSH world, a reference is necessary. 4) There is no mention of what happens if the value proposed by the host and the values supported by the server do not match. Moderate issue: The IETF does not normally use "reference implementations." Therefore, it would be helpful if early in this document there were text describing what the reference implementation is, how it is found, and what the relationship of that reference implementation to this RFC is. I believe that the wording on hierarchy in section 5, paragraph 3 is exactly the opposite of what is shown in the figure. (And what is shown in the figure matches what I would expect.) The text says: Secure groups can be configured as hierarchies where a TH of one group can be a client of one or more other groups operating at a lower stratum. But in fact, what I think happens is that a client of one group operates as the TH of a group operating at a lower stratum. Section 10, the paragraph that begins "[T]he extension field parser initializes a pointer..." has some sort of problem. After reading this several times, I am pretty sure that "the length" by which the pointer is increment is the length in the extension header, not the length computed by subtracting the NTP header from the packet length. If so, please insert test (probably after the "greater than 20" check and before the "not multiple of 4 check") that describes something like "The extension header is found immediately after the NTP header. The length of the extension header is checked to ensure that this length plus the 20 bytes for the MAC header does not exceed the calculated remaining octets of the packet." Minor issues: In figure 5, it would probably help the reader if the groups and hosts were not named identically. (Even just calling the groups Alice-Group and Carol-Group would help.) In section 5, in the description of "[t]he steps in hiking the certificate trails...", in step 1, in the second sentence, could you please add language to make it clear that what the server is "exchanging host names and negotiating..." with is the server from whom it is getting information. It took rereading the list to realize that this was not about the servers initiating communication with the clients who use them. (Yes, I know that such initiation is impossible. Which is why an extra couple of words would help.) Part of this is because common terminology, and later usage in this document, is that the machine in this role (the "server" who is starting to exchange host names ...) is called the client, if I have parsed the protocol correctly. Is there any way section 8 could be moved earlier in the document? One of the problems reading the document is that various parts early in the document assume properties of the system which hav
Re: [Gen-art] draft-ietf-sip-eku-05.txt
Francis Dupont wrote:
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.
Francis: Thank you for your review of the draft. More inline.
Nits/editorial comments:
(I apologize to have been late to send this review)
- 1.2 page 3: X.680 [5],X.690 [6]. -> X.680 [5], X.690 [6].
Thanks, will fix with any other comments from IETF LC.
- 3 page 4:
the application need not recognize -> needs???
(BTW the spelling error, if it is an error, is in RFC 5280)
I believe that in this context, "need" is grammatically
correct -- "needs not recognize..." does not seem to read very
well.
PS: I don't comment about the EKU idea, I've seen some PKI experts in
Acknowledgments so I expect you do the right thing.
Yes; the draft was socialized extensively with PKIX WG. We
even had a WG meeting slot to present the work and solicit
face-to-face comments from PKIX during the formation of the
work. The LC in SIP also was CC'd to the PKIX WG and
comments solicited from that as well.
Thank you.
- vijay
--
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA)
Email: v...@{alcatel-lucent.com,bell-labs.com,acm.org}
Web: http://ect.bell-labs.com/who/vkg/
___
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-geopriv-http-location-delivery-14
Hi Mary, Responses inline. I've edited out sections that I think we have closure on. On Jun 8, 2009, at 1:55 PM, Mary Barnes wrote: [...] -- Section 6.2, value list: -- In my previous review, I was confused as to the relationship between the geodetic/civic and LoBV/LoBR choices. I think it's worth some clarification in this section that geodetic and civic imply LoBV. [MB] Okay, how about the following: OLD: geodetic: The LIS SHOULD return a geodetic location for the Target. civic: The LIS SHOULD return a civic address for the Target. NEW: geodetic: The LIS SHOULD return a location by value in the form of a geodetic location for the Target. civic: The LIS SHOULD return a location by value in the form of a civic address for the Target. Thanks, that helps. -- section 9.3, 5th paragraph: "A temporary spoofing of IP address could mean that a device could request a Location Object or Location URI that would result in another Device's location." It might be worth clarifying that (if I understand correctly) that this is more than a spoofing attack, in that the attacker must not only spoof its source address, but must be able to receive packets sent to the spoofed address? [MB] That statement was intended to include both those items, I'd propose to clarify as follows: NEW: A temporary spoofing of IP address could mean that a device could request a Location Object or Location URI that would result in receiving another Device's location if the attacker is able to receive packets sent to the spoofed address. Thanks, that helps. -- same paragraph: "... re-use of the Device's IP address could result in another Device receiving the original Device's location rather than its own location." It seems like this problem is pretty unlikely to occur by _accident_ when HELD is used over TCP (the only binding right now), right? And certain not to happen over TLS? Might be worth a "mitigating" mention. [MB] Certainly, it is fairly unlikely (if not impossible in most situations), but the recommendations in the bullet points further reduce the potential for problems in the off chance that this occurs. It's not entirely clear to me why you suggest this is certain not to happen over TLS since this is talking about a device that has dropped and thus the connection would drop and it would seem there's a window for another device (although quite unlikely) to use that same IP address. But, perhaps, qualifying the statement as follows would address your concern: OLD: These exposures are limited by the following: NEW: While these situations are fairly unlikely to occur (in particular with the use of TCP/TLS), the exposures can be further limited by the following: On reflection, it's probably better to err on the side of caution here, rather than try to dilute the warning. I withdraw my comment, and think the original text is fine here. Sorry for the flip-flop. Thanks! Ben. ___ 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-geopriv-http-location-delivery-14
On Jun 8, 2009, at 4:21 PM, Mary Barnes wrote: I guess I'm still missing your original concern. But, one problem with that sentence is that it's really out of context and would make more sense if it were the first sentence in the last paragraph in section 8, as that then leads to the text on the recommended mechanism (i.e., TLS). The sentence in question was added in the -12 version when we added a lot more text on HTTP guidelines and it likely should have been merged then with the existing text related to security mechanisms. Remember, my concern was not a question of clarity of text--rather it was an attempt to shine a light on what I think is an important architectural "feature" that some people may find controversial. It's not that I thought it was buried or something--I just know the IESG has a really big reading load, and thought this feature deserved an "in case you didn't notice" sort of comment. Maybe I caused confusion by including this in the "minor issue" section--I did not mean it to be so much an "issue" as a "comment". In particular, I read the text to fairly clearly say that, for the HTTP binding, the LIS cannot use digest or basic authentication, and that the only current device authentication mechanism is the inherent reverse routability check. Unless that was somehow _not_ the intent, then I don't think the text requires clarification per se. Some motivating text might be helpful, i.e. the part about having to work with clients with no previous relationship and therefore no shared secret. OTOH, Martin, in a separate email, indicated that he read the text to say the LIS cannot _rely_ on digest or basic authentication, which is subtly different. If that was the intent, then I think the text _does_ need clarification. You are correct that the device is the HTTP client the the LIS the HTTP server, so the reference should have been to section 9.3 - sorry. Mary. -Original Message- From: Ben Campbell [mailto:b...@estacado.net] Sent: Monday, June 08, 2009 2:27 PM To: Barnes, Mary (RICH2:AR00) Cc: Richard Barnes; General Area Review Team; james.winterbot...@andrew.com; martin.thom...@andrew.com; barbara.st...@att.com; acoo...@cdt.org; Cullen Jennings; i...@ietf.org Subject: Re: Gen-ART LC Review of draft-ietf-geopriv-http-location-delivery-14 Again, my point was not to say that this was necessarily a problem--I highlighted it as something the IESG should think about, knowing that they have a big reading load. I guess my question is, is the statement that reverse routability provides "sufficient assurance in many cases", along with the fact that the HTTP binding explicitly discourages stronger client authentication mechanisms acceptable to them. If it is, I am fine with it, and the draft would not need a change. If on the other hand I have misunderstood something, that's different. I am a little confused about the proposed change to section 8, though. It sounds like it is conflating LIS authentication with device authentication. To decompose your proposed language I read it as: "The LIS SHOULD NOT ... use [device authentication mechanism], but rather SHOULD use [LIS authentication mechanism]" Is it possible I am misunderstanding the direction of the client- server relationship in the HTTP binding? I was assuming the device to be the HTTP client and the LIS to be the HTTP server--do I have it backwards? On Jun 8, 2009, at 2:12 PM, Mary Barnes wrote: Hi Ben, So, you are talking about section 9.3 which does state that the LIS ensures that the client is authenticated, per the following: "The LIS MUST verify that the client is the target of the returned location, i.e., the LIS MUST NOT provide location to other entities than the target. And the following: A prerequisite for meeting this requirement is that the LIS must have some assurance of the identity of the client. Since the target of the returned location is identified by an IP address, simply sending the response to this IP address will provide sufficient assurance in many cases. This is the default mechanism in HELD for assuring that location is given only to authorized clients; LIS implementations MUST support a mode of operation in which this is the only client authentication. And, then the text goes on to some of the other text in section 9.3 that you had questions about that I responded to in a separate email. So, I'm not certain I understand the problem IF I make the proposed change to the sentence in section 8. Mary. -Original Message- From: Ben Campbell [mailto:b...@estacado.net] Sent: Monday, June 08, 2009 1:47 PM To: Barnes, Mary (RICH2:AR00) Cc: Richard Barnes; General Area Review Team; james.winterbot...@andrew.com; martin.thom...@andrew.com; barbara.st...@att.com; acoo...@cdt.org; Cullen Jennings; i...@ietf.org Subject: Re: Gen-ART LC Review of draft-ietf-geopriv-http-location-delivery-14 Hi Mary, The part I was tryi
[Gen-art] Gen Art review of draft-ietf-ospf-ospfv3-mib-14.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). Document: draft-ietf-ospf-ospfv3-mib-14.txt Reviewer: Avshalom Houri Review Date: 2009-06-09 IETF LC End Date: 2009-06-11 IESG Telechat date: (not known) Summary: The document is ready for publication as a Proposes Standard Major issues: None Minor issues: None Thanks --Avshalom ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] review of draft-ietf-sipping-cc-framework-11.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-ietf-sipping-cc-framework-11.txt Reviewer: Francis Dupont Review Date: 2009-06-09 IETF LC End Date: 2009-06-09 IESG Telechat date: unknown Summary: Ready Major issues: None Minor issues: None Nits/editorial comments: - in Abstract page 2: SIP -> Session Initiation Protocol (SIP) - ToC page 3: Far fork -> Far-fork (or Near-fork -> Near fork but fixing the far branch seems better) - Toc page 4: Acknowledgements -> Acknowledgments (IETF/RFC Editor spelling) - 2.3 page 10: the UA abbrev should be introduced (and IMHO far before) - 2.4.2.1 page 12: large- scale -> large-scale - 2.6.7.2 page 17: the IVR abbrev must be introduced - 3.3.2 page 26: from controller) -> from controller): - 3.3.2 page 26: i.e. -> i.e., (same for other i.e. and e.g.) - 3.3.5 page 28: a central mixer) -> a central mixer). - 3.3.8 page 29 (title): Far fork -> Far-fork - 3.2.8 page 30: forked-media -> forked media ? - 4 page 30: The class ... include -> includes ? - 6.31 page 39: (ex: -> (e.g., - 7 page 39 (title): Acknowledgements -> Acknowledgments Regards francis.dup...@fdupont.fr ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] Gen-art review of draft-hollenbeck-rfc4931bis-01
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 wait for direction from your document shepherd
or AD before posting a new version of the draft.
Document: draft-hollenbeck-rfc4931bis-01.txt
Reviewer: Vijay K. Gurbani
Review Date: June 9, 2009
IESG Telechat date: June 11, 2009
Summary: This draft is ready for publication as a Proposed Standard.
The draft has 0 major issues, 0 minor issues, and 0 Nits/Editorial
comments.
Thanks,
- vijay
--
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA)
Email: v...@{alcatel-lucent.com,bell-labs.com,acm.org}
Web: http://ect.bell-labs.com/who/vkg/
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] Gen-ART Review of draft-ietf-geopriv-civic-address-recommendations-02
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-geopriv-civic-address-recommendations-02 Reviewer: Pete McCann Review Date: 09 June 2009 IETF LC End Date: 09 June 2009 IESG Telechat date: (unknown) Summary: Ready with nits Major issues: none Minor issues: none Nits/editorial comments: Section 3: s/ambigious/ambiguous/ s/receipients/recipients/ s/in border region/in a border region/ s/PIDF-LO elements/PIDF-LO Elements/ Section 4: s/interopability/interoperability/ Section 4.1, item 2: s/whether or not they are/whether or not it is/ Section 4.1: s/container, however,/container; however,/ Section 4.2.2: s/exclusively, alternatively/exclusively; alternatively,/ Section 4.2.3: s/optional or not to be used, and/optional, or not to be used, an/ s/must not be used, street suffixes/must not be used. Street suffixes/ Section 4.2.4: s/address consideration/address considerations/ Section 4.2.5: s/local names itself identify/local name itself identifies/ s/may either assist/may assist/ s/In case that/In the case that/ s/docuiment/document/ s/receipients/recipients/ Section 4.2.6: s/address consideration/address considerations/ s/RECOMMENDED, however,/RECOMMENDED; however,/ Section 6.1.3: s/Registration are sorted/Registrations are sorted/ Section 6.2: s/form the official/from the official/ s/Austrian Building an Habitation registry/Austrian Building and Habitation registry/ Appendix A: s/an uniform/a uniform/ s/whole Austria/the whole of Austria/ Section A.1: s/optional, the other Elements/optional, and the other Elements/ Section A.6: s/URI to his RFC/URI to this RFC/ ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
