Re: [secdir] secdir review of draft-sakane-dhc-dhcpv6-kdc-option
Just to make public what I have hinted at privately, I think that steps in section 4.1 may be somewhat underspecified. They give the logic a client, one which supports both DHCP and DNS, should follow in order to find a KDC, with DNS information being preferred. One scenario outlined in section 1 is of a user having entered userid and passphrase and waiting to be authenticated. The steps imply a number of timeouts in succession without specifying what balance to take of how long to wait for a server to respond versus how long to keep the user waiting. I would find it difficult to know what balance to strike without guidance. A related issue is that section 4.1 prefers DNS to DHCP for Kerberos information but the Security Considerations stress the weakness of DHCP and recommend authenticating DHCP. What if DHCP is secure and DNS is not? Should DNS still be preferred? Tom Petch - Original Message - From: Jeffrey Hutzelman jh...@cmu.edu To: Samuel Weiler weiler+sec...@watson.org Cc: draft-sakane-dhc-dhcpv6-kdc-opt...@tools.ietf.org; sec...@ietf.org; ietf@ietf.org; jh...@cmu.edu Sent: Thursday, May 24, 2012 6:50 PM Subject: Re: [secdir] secdir review of draft-sakane-dhc-dhcpv6-kdc-option
Re: [decade] FW: Last Call: draft-farrell-decade-ni-07.txt (Naming Things with Hashes) to Proposed Standard
Hiya, On 06/08/2012 01:35 AM, Jonathan A Rees wrote: On Thu, Jun 7, 2012 at 3:15 PM, Stephen Farrell stephen.farr...@cs.tcd.ie wrote: On 06/06/2012 09:33 PM, Jonathan A Rees wrote: As requested I am sending comments on this last call draft to ietf@ietf.org. I sent them to the authors on 6 May but received no reply. Once again, sorry about that. No idea why I missed responding, your mail is in my client even. Ah well. Jonathan Rees -- Forwarded message -- From: Jonathan A Rees r...@mumble.net Date: Sun, May 6, 2012 at 7:57 PM Subject: comments on http://tools.ietf.org/html/draft-farrell-decade-ni-06 To: Alexey Melnikov alexey.melni...@isode.com, Barry Leiba barryle...@computer.org, S. Farrell stephen.farr...@cs.tcd.ie, P. Hallam-Baker pba...@verisign.com Here are some opinions on http://tools.ietf.org/html/draft-farrell-decade-ni-06 : I think this URI scheme would be a welcome addition to web architecture. Wide review should be sought, because this might become quite important and if there are problems they will be very difficult to fix later. I think using .well-known is a good idea. I think integration into the ecosystem, such as browser support, should be anticipated; for this reason I think content type should be elevated from an 'optional feature' to a 'required feature'. [i.e. conformant implementations must support it, even if providing the content type in the URI is itself optional.] I could certainly live with that, and I suspect my co-authors too, but I'd need to ask 'em. However, we'd like to see more support for it before doing that. If we only hear from you on this, then I think leaving it in the other draft would be right. (See below for why we want to keep that draft.) I guess others have a few weeks to chime in on this. OK, I suspect I can find other W3C TAG members who would agree; will circulate. Great. Just note though that in figuring rough consensus its not really useful for a bunch of (esp. previously unknown) people to just say +1 to something. A note like yours that shows they've read the draft and have their own comment is much more useful. (Its happened in the past that quite well-meaning folks have jumped in like that and with no context it makes it hard for anyone to figure what to make of things.) It is certainly strongly promoted by the W3C web architecture document, see http://www.w3.org/TR/webarch/#internet-media-type so I think I have W3C consensus (as of 2005) behind my claim. Well I could argue that that says that protocols SHOULD do stuff and we're just defining the URI here and not a protocol. But let's see if we get more input on this. If you don't do this, you are just encouraging sniffing and privilege escalation attacks. Sniffing would be a big step backwards. Better to do what the data: scheme does and say that there is a default content type of, say, text/plain, and that otherwise the content type ought to be specified in the URI. Content-type privilege escalation risk (and incorrect sniffing risk) should be mentioned in the security considerations section in any case. Would appreciate text if you can offer some. (Always happy to make the sec. cons. bit better.) Hmm. Hot potato. Maybe something can be derived from Adam's draft http://tools.ietf.org/html/draft-abarth-mime-sniff-06 which I assume you've seen... obviously I'd prefer you do the drafting, but will consider myself pressured. I look forward to seeing that text then:-) Maybe the risk that the host used for retrieval might be spoofing the content-type (by providing a bogus content-type in an HTTP response) should also be mentioned. Good one. Yep, we should mention this whereever ct= is described No, this is a threat even if ct= isn't used. Suppose that the document is intended as an unscriptable media type, but the (malicious) server sets the content-type: header in the response to a scriptable type. Not good. I think this threat is described in Adam's draft. Ta. (A possible design would be to put the content-type (and maybe other headers like Expires:?) in the hashed content, to be pulled out into the HTTP response when the content is served by an http server and then checked by the client, but I understand that this would be a tooling headache.) Yep. We thought about it but agree that it gets too complex too quickly. Maybe with a bit of experience... (I don't understand why you want to separate the 'optional' features into a separate spec. This made me miss the ct= feature entirely at first.) The intent is to put stuff there if we're not sure if its ready or needed everywhere. ct= is definitely the main candidate feature for moving to the base spec though. Some other things (e.g. handling dynamic content) are way more experimental and should definitely not move and maybe need more time before we want them in an RFC. If all this does get popular then the RFCs can be
Re: Comments on draft-farrell-decade-ni-06
Hi Bjoern, Thanks for the feedback! On 06/08/2012 03:16 AM, Bjoern Hoehrmann wrote: Hi, In http://tools.ietf.org/html/draft-farrell-decade-ni-06 the RFC 2119 Just to note that -07 is the version for IETF LC. But your comments apply as well to that, so that's fine. If its useful, I've a working copy of this at [1] that has the changes below as well as a bunch based on other comments received so far. [1] http://down.dsg.cs.tcd.ie/misc/draft-farrell-decade-ni.txt boilerplate does not belong in an Introduction section, it should be in a Terminology or Conformance or similarily named section. What we have is very common in RFCs. For a URI scheme specification having no example of what the syntax is prior to section 8 (or 4 if you spot it there) is a bad idea, there should be one much earlier so you can get an idea what this is about without a lot of reading. Fair enough, added one to the intro. The terms CoAP and DECADE require references in section 9.x since they are not introduced or used anywhere else, if the terms are kept. I do not think General applicability with initial use cases provided by CoAP and DECADE is a useful description for the kind of application that may make use of this scheme, even if there were references. Suggestions for text that'd work welcome. I agree that the CoAP and DECADE mentions should probably go, so for now it just says General Applicability. The Contact field should identify a Person, there should be a name at least. Sure. That'd be me I guess:-) Section 7 references a Wikipedia article by bare address. That should be a proper reference, called [Wikipedia] for instance, or it should at least be on an indended paragraph of its own. It's very distracting when flowing text is mixed with formal syntax, especially when using URLs in a URL scheme specification (the preceding address was an example, not a link.) I've no idea what change to section 7 you mean. I'd welcome a better reference for magnet if someone can offer one but we looked and didn't find one. In section 4, Note that since the .well-known name-space is not intended for general information retrieval, if an application de-references a .well-known/ni URL via HTTP(S), then it SHOULD expect to receive a 30x HTTP re-direction response and it MUST be able to handle this. Put another way, a server SHOULD return a 30x response when a .well- known/ni URL is de-referenced. This is a confusing use of RFC 2119 keywords (put another way would generally suggest the two formulations mean the same thing, but they do not). I would say something like servers SHOULD and clients MUST, which would also remove the confusing SHOULD expect. While I think its ok, I guess SHOULD expect is a bit dodgy, so I've tweaked it to say: Note that since the .well-known name-space is not intended for general information retrieval, if an application de-references a .well-known/ni URL via HTTP(S), then it will often receive a 30x HTTP re-direction response. A server responding to a request for a .well-known/ni URL SHOULD therefore return a 30x response and a client sending such a request MUST be able to handle that. It's not immediately clear whether the schemes define a default value for the authority component. Some definition using the word default would help, including saying there is no default. See RFC 3986 section 3.2.2. for why this matters. Good catch. I've added a statement that there is no default. In section 3 the MUST in decoders MUST recognize is incorrect, that re-states RFC 3986 requirements and should not be rendered as a new con- formance requirement. Say that RFC 3986 requires ... or something like that. Ok. I think the requirement in RFC 4395 section 2.6 applies here, there are text fields in 'ni' and 'nih' addresses, so there needs to be some dis- cussion about I18N and IRI issues, or a statement that there are none, or something along those lines. What if I want a non-ASCII host name in them, for instance? Hmm. So what are the reasonable options for that? I guess I'd prefer to just copy from (or reference) something else that's deployed and works, and not invent anything here. I've put in a placeholder in my working copy. I may have missed it, but I did not see much error handling defined, say how you might handle `ni:///sha-256;%F6...` or perhaps more importantly `ni:///sha-256;f4Ox%20...` given that some Base64 implementations might simply silently strip white space characters and perhaps ignore or mis- treat non-base64 characters. The Security Considerations should mention such parsing issues. Good point. I'd welcome suggestions for what to say there. I've put in a placeholder in my working copy. It's not clear to me that it is a good idea to use `http://h-authority/` as example. It would seem better to use, say, `http://example.org/`. Not sure how to use that there, since h-authority isn't an example
Re: Last Call: draft-hoffman-tao4677bis-15.txt (The Tao of IETF: A Novice's Guide to the Internet Engineering Task Force) to Informational RFC
Sigh. These multiple threads are, IMO, a wonderful exposition of how the IETF can waste a tremendous amount of collective time and energy fine-tuning a document and/or procedures by a very large committee. If nothing else, the process often leads to victory by exhaustion as people just give up, leaving the discussion who have the energy (or, as a colleague would put it, too much time on their hands. I plead somewhat guilty for getting sucked back in, but I want to make a few suggestions: (1) Can we figure out a way to converge on whether we are editing an RFC-to-be by committee or planning something web-ish (not distinguishing between web page and wiki for the moment? If the former, then there are several irrelevant threads. If the latter, then there are a lot of useful comments that should be handled in a different way. (2) At one time, one of the key differences between the IETF and other bodies in more or less the same business was that we allowed ourselves considerable flexibility to match how we did things to the situation and our needs while those other bodies had to spend huge amounts of energy getting agreement on the exact way that something should be done before attempting to do it. If we are going down the web-ish path and haven't lost that sense of flexibility entirely, I would like to recommend that we perform a let's try this, see how it works, and then work out specific procedures for the future experimental engineering process rather than trying to get the details right by committee. In particular, I suggest that, for the initial round of turning the current I-D into something web-ish and establishing a model for handling suggestions and changes, we: Ii) We appoint an Editor (or Editor-in-chief). (ii) Based on precedent, history, a much-better-than-decent job, authorship of the I-D, and an orderly transition from one publication model to the other, we should appoint Paul by acclamation. By that I mean that someone, ideally Russ, gets on the list and says is there really any objection to appointing Paul... if not, done. That skips, for the present, wasting more time figuring out who makes the appointment, whose approval is needed, whether we need a whole process (e.g., of volunteers, lists and comments) similar to how we handle IAOC and ISOC BoT appointments, and a whole series of other ways in which we could waste a lot of time and then get the same result. (iii) Let's give the Editor six or nine months of discretion and experimental time about formats (let's at least start with a controlled list of people who can make changes until we have a document in place and a bit of experience -- I see no substantive difference between a controlled-authorship Wiki and a controlled-authorship web page other than the tools used although we could spend lots of time debating the non-substantive differences), editorial board composition, how to solicit and receive input, etc. We encourage the editor to consult with the IESG to the extent to which the IESG (or some IESG-chosen subcommittee) is inclined to be involved. (iv) At the end of that period, we see if we can find an efficient way to examine the experience, draw ideas together, and figure out what we really want to do for the long term and what procedures are needed to do it. I think I just said BOF in Atlanta or Orlando rather than mail storm on the IETF list, but, if we need to do a mail storm, let's at least have some experience and a web-based document on which to focus, rather than trying to have editorial, procedural, organizational, and format suggestions all mixed up with each other. If we all really have this many spare cycles, perhaps many of them would be better spent getting the document (page, wiki,...) right rather than tuning procedures. Perhaps some of them might even be better invested in protocol specification. And, on that note, I'm going to go try to spend a little time on a neglected WG. best, john
Re: [secdir] secdir review of draft-sakane-dhc-dhcpv6-kdc-option
On 6/8/2012 3:37 AM, t.p. wrote: Just to make public what I have hinted at privately, I think that steps in section 4.1 may be somewhat underspecified. They give the logic a client, one which supports both DHCP and DNS, should follow in order to find a KDC, with DNS information being preferred. Yes, this is because the DNS auth models are better than DHCP today AFAIK. One scenario outlined in section 1 is of a user having entered userid and passphrase and waiting to be authenticated. The steps imply a number of timeouts in succession without specifying what balance to take of how long to wait for a server to respond versus how long to keep the user waiting. True but this is likely to be set in the client as a flat config value one would think. And if so this is actually a good thing you bring up Tom. My take is that from a policy management standpoint the timeout period should be a policy level control IMHO and should have both a default value and a method of overriding it to allow people when they need to to create a more synchronous expectation from a responder. I would find it difficult to know what balance to strike without guidance. A related issue is that section 4.1 prefers DNS to DHCP for Kerberos information but the Security Considerations stress the weakness of DHCP and recommend authenticating DHCP. What if DHCP is secure and DNS is not? Should DNS still be preferred? DNSSEC is clearly beyond DHCP security models so perhaps for a working system this makes sense unless you want to create an autonomous DNS client which can exist in a pre-boot model. Pardon my restating the obvious but Still the issue is that DNS services dont work until they are loaded and DHCP is designed to work from a firmware boot (as we all know). How does this fit into what NEA is supposed to provide as a baseline? Tom Petch - Original Message - From: Jeffrey Hutzelmanjh...@cmu.edu To: Samuel Weilerweiler+sec...@watson.org Cc:draft-sakane-dhc-dhcpv6-kdc-opt...@tools.ietf.org; sec...@ietf.org;ietf@ietf.org;jh...@cmu.edu Sent: Thursday, May 24, 2012 6:50 PM Subject: Re: [secdir] secdir review of draft-sakane-dhc-dhcpv6-kdc-option - No virus found in this message. Checked by AVG - www.avg.com Version: 2012.0.2178 / Virus Database: 2433/5055 - Release Date: 06/07/12
Re: [secdir] secdir review of draft-sakane-dhc-dhcpv6-kdc-option
- Original Message - From: ssakane ssak...@cisco.com To: t.p. daedu...@btconnect.com Cc: draft-sakane-dhc-dhcpv6-kdc-opt...@tools.ietf.org; sec...@ietf.org; ietf ietf@ietf.org Sent: Friday, June 08, 2012 2:29 PM Hi Tom, Some reviewers suggested me to just remove the figure and its description in 4.1 because it has ambiguity. I think it would be better to leave the 1st paragraph in section 4.1, and I should remove the rest. What do you think about this idea ? I would leave it in. The first paragraph on its own I would think underspecified and the rest of the section does cover a number of issues, issues that only occurred to me when I read the section carefully. As I said in my last post, I then found I had further issues - how long to wait, should a secure DHCP trump an insecure DNS? - which may be worth exploring in addition. I do think that this kind of pseudocode helps a lot of developers to understand the issues and would want a good reason to remove it; at the same time, others see it as an impurity that has no part in a Standards Track RFC. One option would be to remove it to an Appendix which implicitly makes it Informative and not Normative so it is there for those who would benefit from it but will not upset those who consider it out of place. But I would bounce this off the krb list to see what reaction you get. Tom Petch Thanks, Shoichi On 6/8/12 7:37 PM, t.p. daedu...@btconnect.com wrote: Just to make public what I have hinted at privately, I think that steps in section 4.1 may be somewhat underspecified. They give the logic a client, one which supports both DHCP and DNS, should follow in order to find a KDC, with DNS information being preferred. One scenario outlined in section 1 is of a user having entered userid and passphrase and waiting to be authenticated. The steps imply a number of timeouts in succession without specifying what balance to take of how long to wait for a server to respond versus how long to keep the user waiting. I would find it difficult to know what balance to strike without guidance. A related issue is that section 4.1 prefers DNS to DHCP for Kerberos information but the Security Considerations stress the weakness of DHCP and recommend authenticating DHCP. What if DHCP is secure and DNS is not? Should DNS still be preferred? Tom Petch - Original Message - From: Jeffrey Hutzelman jh...@cmu.edu To: Samuel Weiler weiler+sec...@watson.org Cc: draft-sakane-dhc-dhcpv6-kdc-opt...@tools.ietf.org; sec...@ietf.org; ietf@ietf.org; jh...@cmu.edu Sent: Thursday, May 24, 2012 6:50 PM Subject: Re: [secdir] secdir review of draft-sakane-dhc-dhcpv6-kdc-option
Re: Last Call: draft-hoffman-tao4677bis-15.txt (The Tao of IETF: A Novice's Guide to the Internet Engineering Task Force) to Informational RFC
On Jun 7, 2012, at 10:20 PM, Paul Hoffman wrote: On Jun 7, 2012, at 6:13 PM, Bradner, Scott wrote: On Jun 7, 2012, at 7:09 PM, Paul Hoffman wrote: On May 30, 2012, at 11:22 PM, Eliot Lear wrote: • It's probably worth adding a word or two about the fact that the ISOC Board is the final appellate avenue in the standardization process. In this way it may also make sense to move Section 3.2.1 further back behind the IAB. I have heard that as well, but cannot find it in RFC 2026 or any of the RFCs that update 2026 (3667 3668 3932 3978 3979 5378 5657 5742 6410). It should only be in the Tao if we can point to where the rule comes from. see RFC 2026 section 6.5.3 6.5.3 Questions of Applicable Procedure Further recourse is available only in cases in which the procedures themselves (i.e., the procedures described in this document) are claimed to be inadequate or insufficient to the protection of the rights of all parties in a fair and open Internet Standards Process. Claims on this basis may be made to the Internet Society Board of Trustees. The President of the Internet Society shall acknowledge such an appeal within two weeks, and shall at the time of acknowledgment advise the petitioner of the expected duration of the Trustees' review of the appeal. The Trustees shall review the situation in a manner of its own choosing and report to the IETF on the outcome of its review. The Trustees' decision upon completion of their review shall be final with respect to all aspects of the dispute. note that the appeal to the ISOC BopT is only if the claim is that the rules are broken not the application of the rules Exactly right. What Eliot said, and others have said, is that the ISOC board is the final appellate avenue in the standardization process. That's quite different than the rules are broken. just to be clear - saying final appellate avenue in the standardization process. could be read as meaning that a appeal of a technical decision could be made to the ISOC Board and that is not the case - this is why I used different language not sure which you were supporting Scott there has never been such an appeal Happily noted. --Paul Hoffman
Re: Last Call: draft-hoffman-tao4677bis-15.txt (The Tao of IETF: A Novice's Guide to the Internet Engineering Task Force) to Informational RFC
On Jun 8, 2012, at 12:46 PM, Bradner, Scott wrote: just to be clear - saying final appellate avenue in the standardization process. could be read as meaning that a appeal of a technical decision could be made to the ISOC Board and that is not the case - this is why I used different language not sure which you were supporting I am supporting not putting anything about appeals to the ISOC Board in the Tao. They do not apply to novices. --Paul Hoffman
Re: Last Call: draft-ietf-6man-lineid-05.txt (The Line Identification Destination Option) to Experimental RFC
Hi Med, On 06/06/2012 08:04 AM, mohamed.boucad...@orange.com wrote: Dear Suresh, all, Even if the document includes several warnings about the unreliability of an RS-based mechanism, I suggest to add a pointer to the following document: http://tools.ietf.org/html/draft-dec-6man-rs-access-harmful-00. Is there something in particular that you think is missing from the lineid draft? The current warning text in lineid (and the reclassification to experimental) was arrived at after consultations with the the 6man chairs and the author of draft-dec. Thanks Suresh
Re: Last Call: draft-hoffman-tao4677bis-15.txt (The Tao of IETF: A Novice's Guide to the Internet Engineering Task Force) to Informational RFC
All, Based on this explanation from Scott I withdraw my suggestion. Text can stay as it is. Eliot On 6/8/12 9:46 PM, Bradner, Scott wrote: On Jun 7, 2012, at 10:20 PM, Paul Hoffman wrote: On Jun 7, 2012, at 6:13 PM, Bradner, Scott wrote: On Jun 7, 2012, at 7:09 PM, Paul Hoffman wrote: On May 30, 2012, at 11:22 PM, Eliot Lear wrote: • It's probably worth adding a word or two about the fact that the ISOC Board is the final appellate avenue in the standardization process. In this way it may also make sense to move Section 3.2.1 further back behind the IAB. I have heard that as well, but cannot find it in RFC 2026 or any of the RFCs that update 2026 (3667 3668 3932 3978 3979 5378 5657 5742 6410). It should only be in the Tao if we can point to where the rule comes from. see RFC 2026 section 6.5.3 6.5.3 Questions of Applicable Procedure Further recourse is available only in cases in which the procedures themselves (i.e., the procedures described in this document) are claimed to be inadequate or insufficient to the protection of the rights of all parties in a fair and open Internet Standards Process. Claims on this basis may be made to the Internet Society Board of Trustees. The President of the Internet Society shall acknowledge such an appeal within two weeks, and shall at the time of acknowledgment advise the petitioner of the expected duration of the Trustees' review of the appeal. The Trustees shall review the situation in a manner of its own choosing and report to the IETF on the outcome of its review. The Trustees' decision upon completion of their review shall be final with respect to all aspects of the dispute. note that the appeal to the ISOC BopT is only if the claim is that the rules are broken not the application of the rules Exactly right. What Eliot said, and others have said, is that the ISOC board is the final appellate avenue in the standardization process. That's quite different than the rules are broken. just to be clear - saying final appellate avenue in the standardization process. could be read as meaning that a appeal of a technical decision could be made to the ISOC Board and that is not the case - this is why I used different language not sure which you were supporting Scott there has never been such an appeal Happily noted. --Paul Hoffman
Re: Last Call: draft-hoffman-tao4677bis-15.txt (The Tao of IETF: A Novice's Guide to the Internet Engineering Task Force) to Informational RFC
wfm On Jun 8, 2012, at 3:49 PM, Paul Hoffman wrote: On Jun 8, 2012, at 12:46 PM, Bradner, Scott wrote: just to be clear - saying final appellate avenue in the standardization process. could be read as meaning that a appeal of a technical decision could be made to the ISOC Board and that is not the case - this is why I used different language not sure which you were supporting I am supporting not putting anything about appeals to the ISOC Board in the Tao. They do not apply to novices. --Paul Hoffman
Re: [decade] FW: Last Call: draft-farrell-decade-ni-07.txt (Naming Things with Hashes) to Proposed Standard
One small comment, that I know the authors are aware of... On 6 June 2012 13:33, Jonathan A Rees r...@mumble.net wrote: I think using .well-known is a good idea. I think that using .well-known is a bad idea. This imposes an unnecessary restriction on the deployment of resources. /.well-known/ is a space that can only be deployed to by an administrator of the system. By identifying specifically where the resource might live (potentially with more than one URL), this avoids the deployment issue. Yes, I am aware of the extensions. And: (a lot of other things) I agree with all of this, the authority thing, the content-type thing. All of it. (And none of the rebuttal.) Nit: The draft makes some strange statements about redirects. Put another way, a server SHOULD return a 30x response when a .well- known/ni URL is de-referenced. Requiring a compliant HTTP implementation that follows redirects is sufficient. What the server does to serve this request is the server's business. Redirects seem likely, but 2119 language for the server is not necessary for interoperation.
Re: [decade] FW: Last Call: draft-farrell-decade-ni-07.txt (Naming Things with Hashes) to Proposed Standard
Hi Martin, On 06/08/2012 10:54 PM, Martin Thomson wrote: One small comment, that I know the authors are aware of... On 6 June 2012 13:33, Jonathan A Rees r...@mumble.net wrote: I think using .well-known is a good idea. I think that using .well-known is a bad idea. Ok. Opinions vary. This imposes an unnecessary restriction on the deployment of resources. /.well-known/ is a space that can only be deployed to by an administrator of the system. By identifying specifically where the resource might live (potentially with more than one URL), this avoids the deployment issue. Yes, I am aware of the extensions. I don't get what you mean above. If its something that implies a change, I don't know what change. And: (a lot of other things) I agree with all of this, the authority thing, the content-type thing. All of it. (And none of the rebuttal.) So the probability of us being completely correct in all this is probably infinitesimally small, but equal to the probability of us being completely wrong. That would imply that our rebuttals are not completely wrong and hence you are equally wrong in saying all and none above. (Isn't sophistry great:-) Anyway, I take that as another +1 for adding ct= to this draft which is fine. I'm starting to think that might be a good plan. Let's see if others (dis)agree during the rest of IETF LC. I also take that as another claim that our use of the authority field is somehow wrong for what seem to me to be near-mystical reasons, with no compelling argument offered as to any bad effects at all ensuing. I'm still entirely happy that our current design is good enough as-is. For me, running code is a winner in that part of the argument. Nit: The draft makes some strange statements about redirects. Put another way, a server SHOULD return a 30x response when a .well- known/ni URL is de-referenced. Requiring a compliant HTTP implementation that follows redirects is sufficient. What the server does to serve this request is the server's business. Redirects seem likely, but 2119 language for the server is not necessary for interoperation. Good point. I've tweaked that a bit in response to Bjoern's comments, but your suggestion above is better than what I have now so I'll work that in. (Actually, is client support for 3xx mandatory according to 2616? Not sure myself.) Thanks, S.
Re: [decade] FW: Last Call: draft-farrell-decade-ni-07.txt (Naming Things with Hashes) to Proposed Standard
Add me as a +1 for the idea that content-type is important for this. I tend to agree with the arguments given so far. Namely, for some important use cases you're going to want to know the content type and guessing is really a bad idea. That said, there are security considerations associated with specifying a content type too. I'm particularly imagining a situation where some sort of deep inspection security appliance uses a different procedure for deciding what kind of foo it is than the ultimate application. One guesses based on byte stream another looks at a content type. This is well known; it's not new; it's probably even so documented that any reasonably current set of MIME security considerations already includes a reference. I agree that your draft does not use the authority portion of a URI consistent with section 3.2 of RFC 3986. The authority separates the namespace exactly the way it doesn't in your scheme. It's a naming hierarchy. My main concern is whether the relative reference algorithm described in section 5/4.2 of RFC 3986. In particular take a look at the last part of section 1.2 of RFC 3986 regarding the disallowing of /. Consider how you want relative references in an HTML document resolved through a ni: URI to work. I don't think your use of authority provides good results. However I'm not sure that better results would be achieved without hierarchy. I hope though that these comments will help inject some ways of reasoning about authority that are less mystical and that lead to more practical discussion.
Re: Last Call: draft-polk-ipr-disclosure-03.txt (Promoting Compliance with Intellectual Property Rights (IPR) Disclosure Rules) to Informational RFC
Hi, I want to thank Peter and Tim to take my comments into account in version 4 of this document. I'm happy with version this version. Regards, Stephan On 4.30.2012 19:19 , Stephan Wenger st...@stewe.org wrote: Hi, Here are a few comments to this draft. Stephan (1) Section 3.1, final paragraph. An IETF disclosure has to be made against a Contribution. In the case described in this paragraph, the Contribution may not have been made at the time of the Disclosure request, and, therefore, it would be impossible to make a Disclosure. For example, if someone wants to discuss a technology verbally, you cannot make an IPR disclosure before the words have been uttered. I would remove this paragraph. Alternatively, limit it to materials you plan to make available at the meeting in the sprit it of section 4.1. (2) Section 3.2, silence may be interpreted as a weak No.. This statement is IMO not supported by the IETF patent policy, and should therefore be removed. Generally speaking, any additional burden to non-Contributors beyond making them aware of the voluntary disclosure opportunity IMP constitutes a policy change and must be avoided. (3) Section 3.3. I would replace author with authors and other Contributors. Or known Contributors, prominent Contributors, or something like this. It is entirely possible, and in fact not uncommon, that non-author Contributors influence the technology choices of I-Ds. One possible metric for identifying some of these Contributors would be a review of the Acknowledgement section many I-Ds include. I see this mentioned in section 3.4; I would shift (or duplicate?) the burden of double-checking with Contributors to the WG chairs as WGLC. (4) Section 4.2. Suggest to include Contributors in the spirit of comment (3) above. (5) Section A.1. The email has a logical structure, but sometimes a logical structure may not have the best effect. As written, people will probably not read it in its entirety, but will give up once its clear that it includes legalese. Suggest to move the final paragraph As FOO WG chairs to the top, and put the formal justification stuff at the end. (6) Section A.2: I would substitute Dear FOO WG with Dear FOO WG and especially authors and Contributors: (7) Section A.2, third paragraph, sentence We will not be able to advance this document to the next stage until we have received a reply from each author and listed contributor. If this sentence starts appearing with some consistency in IETF WGs, then we have a de-facto policy change (requiring affirmative negative declarations). Suggest to soften the language: we may not be able to advance or it does not appear to be sensible to us to advance (8) Section A.2, fourth paragraph: I would express this along the following: you are reminded of your opportunity for a voluntary IPR disclosure under BCP79 section xxx. Unless you want to make such a voluntary disclosure, please do not reply. (9) Section A.3, see previous comments (7) and (8). (10) Section A.4, see previous comment (7) (11) Section A.5, see previous comment (7) On 4.30.2012 18:27 , The IESG iesg-secret...@ietf.org wrote: The IESG has received a request from an individual submitter to consider the following document: - 'Promoting Compliance with Intellectual Property Rights (IPR) Disclosure Rules' draft-polk-ipr-disclosure-03.txt as Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2012-05-28. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract The disclosure process for intellectual property rights (IPR) in documents produced within the IETF stream is essential to the accurate development of community consensus. However, this process is not always followed by participants during IETF standardization. Regardless of the cause or motivation, noncompliance with IPR disclosure rules can derail or delay completion of standards documents. This document describes strategies for promoting compliance with the IPR disclosure rules. The strategies are primarily intended for area directors, working group chairs, and working group secretaries. The file can be obtained via http://datatracker.ietf.org/doc/draft-polk-ipr-disclosure/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-polk-ipr-disclosure/ballot/ No IPR declarations have been submitted directly on this I-D.
Re: Last Call: draft-hoffman-tao4677bis-15.txt (The Tao of IETF: A Novice's Guide to the Internet Engineering Task Force) to Informational RFC
On Thu, 2012-06-07 at 16:09 -0700, Paul Hoffman wrote: ... • The Tao mentions that we meet once a year in each region. I don't think that's true for Asia at this point. The text might call out that we meet where there are participants, or words that the IAOC might provide. It doesn't say that. It says approximately once a year in each region. That is still true. A quick check of the Upcoming IETF Meetings calendar (http://www.ietf.org/meeting/upcoming.html) shows that the next meeting in Asia is scheduled for November 2015, while the last was November 2011. How does a 4 year gap map to approximately once a year? ...
Re: [decade] FW: Last Call: draft-farrell-decade-ni-07.txt (Naming Things with Hashes) to Proposed Standard
Hi Sam, On 06/09/2012 01:43 AM, Sam Hartman wrote: Add me as a +1 for the idea that content-type is important for this. I tend to agree with the arguments given so far. Namely, for some important use cases you're going to want to know the content type and guessing is really a bad idea. Thusly counted:-) That said, there are security considerations associated with specifying a content type too. I'm particularly imagining a situation where some sort of deep inspection security appliance uses a different procedure for deciding what kind of foo it is than the ultimate application. One guesses based on byte stream another looks at a content type. This is well known; it's not new; it's probably even so documented that any reasonably current set of MIME security considerations already includes a reference. My only real concern with adding this is the issue of complexity related to c14n of input to the hash function. While CMS does (I think) define that well, imposing that burden on anyone that might want to write code that validates name-data integrity is an issue. Anyway, if we want to add it we'll look that over and figure how it might best be done. I agree that your draft does not use the authority portion of a URI consistent with section 3.2 of RFC 3986. I honestly don't get that. I think we are consistent with 3986 (there being no MUST/SHOULD with which we're in conflict afaik) but the authority field here is not identical to that for HTTP URLs. And that's ok. The authority separates the namespace exactly the way it doesn't in your scheme. Yes there are differences and maybe we ought try describe that somehow. It's a naming hierarchy. My main concern is whether the relative reference algorithm described in section 5/4.2 of RFC 3986. In particular take a look at the last part of section 1.2 of RFC 3986 regarding the disallowing of /. Consider how you want relative references in an HTML document resolved through a ni: URI to work. I don't think your use of authority provides good results. However I'm not sure that better results would be achieved without hierarchy. I hope though that these comments will help inject some ways of reasoning about authority that are less mystical and that lead to more practical discussion. Thanks. I think your comment about relative URIs is fair and we maybe ought say there are no such things for ni URIs. (Or however that kind of thing is stated best). I guess a sentence or two about relative URIs would be worthwhile and I'll ponder that. S.
Re: [decade] FW: Last Call: draft-farrell-decade-ni-07.txt (Naming Things with Hashes) to Proposed Standard
Stephen Farrell stephen.farr...@cs.tcd.ie wrote: Hi Sam, On 06/09/2012 01:43 AM, Sam Hartman wrote: Add me as a +1 for the idea that content-type is important for this. I tend to agree with the arguments given so far. Namely, for some important use cases you're going to want to know the content type and guessing is really a bad idea. Thusly counted:-) That said, there are security considerations associated with specifying a content type too. I'm particularly imagining a situation where some sort of deep inspection security appliance uses a different procedure for deciding what kind of foo it is than the ultimate application. One guesses based on byte stream another looks at a content type. This is well known; it's not new; it's probably even so documented that any reasonably current set of MIME security considerations already includes a reference. My only real concern with adding this is the issue of complexity related to c14n of input to the hash function. While CMS does (I think) define that well, imposing that burden on anyone that might want to write code that validates name-data integrity is an issue. Anyway, if we want to add it we'll look that over and figure how it might best be done. I agree that your draft does not use the authority portion of a URI consistent with section 3.2 of RFC 3986. I honestly don't get that. I think we are consistent with 3986 (there being no MUST/SHOULD with which we're in conflict afaik) but the authority field here is not identical to that for HTTP URLs. And that's ok. The authority separates the namespace exactly the way it doesn't in your scheme. Yes there are differences and maybe we ought try describe that somehow. It's a naming hierarchy. My main concern is whether the relative reference algorithm described in section 5/4.2 of RFC 3986. In particular take a look at the last part of section 1.2 of RFC 3986 regarding the disallowing of /. Consider how you want relative references in an HTML document resolved through a ni: URI to work. I don't think your use of authority provides good results. However I'm not sure that better results would be achieved without hierarchy. I hope though that these comments will help inject some ways of reasoning about authority that are less mystical and that lead to more practical discussion. Thanks. I think your comment about relative URIs is fair and we maybe ought say there are no such things for ni URIs. (Or however that kind of thing is stated best). I guess a sentence or two about relative URIs would be worthwhile and I'll ponder that. S.
