Re: Abstract on Page 1?
Scott Lawrence wrote: ... This is a trivial change for the generation tools to make - at worst it will make one generation of diffs slightly more difficult (and I'd be happy to trade one generation of poor diffs for this, so for me just don't worry about fixing the diff tools). ... At this point, no change to the boilerplate is trivial anymore. For xml2rfc, we need to - define how to select the new behavior (date? ipr value? rfc number?); if the behavior is not explicitly selected in the source, we need heuristics when to use the old one and when to use the new one (keep in mind that the tools need to be able to generate historic documents as well) - add new test cases - add documentation So, I'm not against another re-organization, but, in this time, PLEASE: - plan it well (think of all consequences for both I-Ds and RFCs) - make the requirements precise and actually implementable (remember: must be on page 1 :-) - give the tool developers sufficient time; optimally let *then* decide when the cutover date should be BR, Julian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: jim bound
It's...sad that a lot of the men and women involved in making some of this countries greatest technological leaps are passing. Many of the men and women who put us on the moon are no longer alive. More and more of the men and women who helped build the bedrock of what became modern computing (including The Internet) are starting to pass as well. --On March 7, 2009 7:24:58 AM + Paul Vixie vi...@isc.org wrote: i shared the news with some coworkers from DEC (where jim and i both worked back in the early 1990's). one of them said: Wow, sorry to hear it. Jim treated networking like he was still in 'Nam and beauracracy was Charlie. He always took the hill. another added: I would only add that he never left any behind. jim will be missed, both sorely and otherwise, by me and by many others. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf -- Genius might be described as a supreme capacity for getting its possessors into trouble of all kinds. -- Samuel Butler ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Running Code
Scott Lawrence wrote: On Tue, 2009-03-03 at 13:17 -0800, Marc Petit-Huguenin wrote: I would like to bring to your attention this proposal to put back running code at the center of Internet protocol design by adding a new Considerations Section in future Internet-Drafts and RFCs: http://www.ietf.org/internet-drafts/draft-petithuguenin-running-code-considerations-00.txt I oppose the addition of such a mandatory or formalized section, despite the fact that I very much support measuring specification quality and community support by looking for running code. I oppose even more this part of the definition of running code: The minimum rights that should be granted for this source code are the right to duplicate it for purpose of reading it and the right to execute it or generate the binary code to execute it. I spend nearly all my time and energy these days on open source software, so this would not be a barrier for me, but it would be for many people whose contributions are important. More importantly, I have no need (or desire) to look at the source code for an implementation to determine whether or not it matches the specification and interoperates with other implementations. It is behavior on the wire that we are concerned with in the IETF - we don't specify how a protocol is implemented, we specify the behavior it exhibits. The reason is to evaluate implementation complexity. Protocol behavior on the wire does not permit to do. Sometimes a protocol or feature are rejected because it is thought to be too complex to implement - a good example would be the time-switch in CPL, where IIRC an implementation permitted to have the calendar feature back in the spec. History-Info is an example of something that is thought more more complex to implement that it is in reality - here also showing some code would have helped to demonstrate that it is not the case. The opposite is probably true, i.e. some protocols or features would have been abandoned when looking at the complexity of implementing it (especially considering the correlation between code complexity and security issues) -- Marc Petit-Huguenin Home: m...@petit-huguenin.org Work: petit...@acm.org ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Running Code
Scott Lawrence wrote: On Tue, 2009-03-03 at 13:17 -0800, Marc Petit-Huguenin wrote: I would like to bring to your attention this proposal to put back running code at the center of Internet protocol design by adding a new Considerations Section in future Internet-Drafts and RFCs: http://www.ietf.org/internet-drafts/draft-petithuguenin-running-code-considerations-00.txt I oppose the addition of such a mandatory or formalized section, despite the fact that I very much support measuring specification quality and community support by looking for running code. I oppose even more this part of the definition of running code: The minimum rights that should be granted for this source code are the right to duplicate it for purpose of reading it and the right to execute it or generate the binary code to execute it. I spend nearly all my time and energy these days on open source software, so this would not be a barrier for me, but it would be for many people whose contributions are important. It seems that there is a general misunderstanding that this draft asks for mandatory source implementation. This is not the case, and this will be better explained in the next version of the draft. What this draft ask for is to be mandatory to list in a specific section the names, authors and sponsors of early implementations available in source form. Everything that does not fall under the definition can still be acknowledged as it is now (or not) in the normal Acknowledgement section. And if there is no early source implementation, then the section is empty. The only burden for the I-D author is to add an entry in the section when an implementer sends a reference. The burden for the RFC editor is to remove the URLs and eventually the whole section if empty before publication as RFC. That's it. On the other hand this give to reviewers an idea of the complexity needed to implement it and a way to evaluate corner cases, security issues and other details that will plague the future production implementations, etc... -- Marc Petit-Huguenin Home: m...@petit-huguenin.org Work: petit...@acm.org ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Running Code
Marc Petit-Huguenin petithug at acm dot org wrote: What this draft ask for is to be mandatory to list in a specific section the names, authors and sponsors of early implementations available in source form. Everything that does not fall under the definition can still be acknowledged as it is now (or not) in the normal Acknowledgement section. And if there is no early source implementation, then the section is empty. Why not simply make the section optional, then, and let authors and WGs include it if they think it will provide better insight into the specification -- or improve its chances of being approved -- and let others ignore it if they choose? -- Doug Ewell * Thornton, Colorado, USA * RFC 4645 * UTN #14 http://www.ewellic.org http://www1.ietf.org/html.charters/ltru-charter.html http://www.alvestrand.no/mailman/listinfo/ietf-languages ˆ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Abstract on Page 1?
On 2009-03-04 16:33 Margaret Wasserman said the following: I would like to propose that we re-format Internet-Drafts such that the boilerplate (status and copyright) is moved to the back of the draft, and the abstract moves up to page 1. I don't believe that there are any legal implications to moving our IPR information to the back of the document, and it would be great not to have to page down at the beginning of every I-D to skip over it. If someone wants to check the licensing details, they could look at the end of the document. +1 Whether or not this is an easy fix for the tools, I think it's the right thing to do, not only for drafts but also for RFCs, as it lets us focus on the technical matter of a document, rather than copyright, other IPR details, and administrivia. Henrik ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Abstract on Page 1?
This seems like a really good idea from a usability perspective, but I've not noticed any feed back from our official or unofficial legal community. My concern would be whether there is a legal requirement that the copyright and other similar declarations be in the front of a document. I'd certainly like to move the copyright and such from the front of every source file I've had to look at. In particular, the book sized declarations often used in the open source community or to conform to various UNIX licenses. I can't recall any examples of any document or source file where the copyright was at the end. It certainly isn't common. David Morris ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Abstract on Page 1?
On Mar 7, 2009, at 1:45 AM, Julian Reschke wrote: So, I'm not against another re-organization, but, in this time, PLEASE: - plan it well (think of all consequences for both I-Ds and RFCs) - make the requirements precise and actually implementable (remember: must be on page 1 :-) - give the tool developers sufficient time; optimally let *then* decide when the cutover date should be BR, Julian +1 Also, There are some changes the IESG needs to deal with, some the IAB, some the Trustees. We should incorporate all of this into one single document that shows clear examples of what things will look like so there is no confusion, then get all required approval bodies to approve it. Having half the changes in one doc, half in another doc results in unintended nightmares when we go to merge. I also propose we do our best to get it right once instead of a steady stream of changing requirements on document authors. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Abstract on Page 1?
On Mar 7, 2009, at 12:21 PM, David Morris wrote: I can't recall any examples of any document or source file where the copyright was at the end. It certainly isn't common. agree it is unusual and weird but much of resiprocate has them at the end because some people had a hard time with the page down key on the first page https://svn.resiprocate.org/viewsvn/resiprocate/main/p2p/ChordTopology.cxx?view=markup ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Running Code
On Mar 3, 2009, at 3:43 PM, Marc Petit-Huguenin wrote: Giving to early implementers a guaranty that their contributions will not be forgotten is a way to counterbalance the time and effort spent in working on this contributions. Marc, I feel that it is well worth thanking anyone in the acknowledgements that does a full or significant early implementation and sends comments to the list about it. Even if that comment is we found no problems with the spec. It is a huge amount of work to test a spec by implementing it and a valuable contribution to the development. If you, or others, see any RAI Area WG drafts that should really acknowledge an implementation, please bring it to my attention. I suspect that many people at IETF would feel it is worth saying thanks for this kind of work, I'd encourage implementors to bring it up with WG draft editors and Chairs if they think someone should be added to the Acknowledgements section. Thanks, Cullen RAI AD PS - Thank you for your TURN implementations - as you know, they have helped find many problems with that spec. I'm off to read the TURN Acknowledgements :-) ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Running Code
Scott Lawrence wrote: On Tue, 2009-03-03 at 13:17 -0800, Marc Petit-Huguenin wrote: I would like to bring to your attention this proposal to put back running code at the center of Internet protocol design by adding a new Considerations Section in future Internet-Drafts and RFCs: http://www.ietf.org/internet-drafts/draft-petithuguenin-running-code-considerations-00.txt I oppose the addition of such a mandatory or formalized section, despite the fact that I very much support measuring specification quality and community support by looking for running code. I oppose even more this part of the definition of running code: The minimum rights that should be granted for this source code are the right to duplicate it for purpose of reading it and the right to execute it or generate the binary code to execute it. I spend nearly all my time and energy these days on open source software, so this would not be a barrier for me, but it would be for many people whose contributions are important. It seems that there is a general misunderstanding that this draft asks for mandatory source implementation. I have seen no evidence of any such misunderstanding. It certainly isn't what Scott objected to above. This is not the case, and this will be better explained in the next version of the draft. What this draft ask for is to be mandatory to list in a specific section the names, authors and sponsors of early implementations available in source form. And that's the problem Scott is referring to, and which I agree is a significant issue. There is no doubt that the process of implementing something provides valuable insight into specification clarity, general implementabiity, and protocol complexity. But the same insights accrue from *any* implementation, irrespective of whether it is done as open source or not. The only advantage an open source implementation has over closed source is that others can look at it. But while this advantage is real, the bias it could create in favor of open source as a means of assessing protocols is just not worth it. Everything that does not fall under the definition can still be acknowledged as it is now (or not) in the normal Acknowledgement section. And if there is no early source implementation, then the section is empty. Right. More pointless boilerplate in all our drafts, more pointless administrivia to deal with. The burden on authors are already too great; we should be looking at ways to reduce them, not increase them. The only burden for the I-D author is to add an entry in the section when an implementer sends a reference. Wrong. Any requirement such as this carries with it the need for enforcement, with all that implies. The burden for the RFC editor is to remove the URLs and eventually the whole section if empty before publication as RFC. That's it. On the other hand this give to reviewers an idea of the complexity needed to implement it and a way to evaluate corner cases, security issues and other details that will plague the future production implementations, etc... And I continue to believe the costs are far greater than the benefits. Ned ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Running Code
Ned Freed wrote: Scott Lawrence wrote: On Tue, 2009-03-03 at 13:17 -0800, Marc Petit-Huguenin wrote: I would like to bring to your attention this proposal to put back running code at the center of Internet protocol design by adding a new Considerations Section in future Internet-Drafts and RFCs: http://www.ietf.org/internet-drafts/draft-petithuguenin-running-code-considerations-00.txt I oppose the addition of such a mandatory or formalized section, despite the fact that I very much support measuring specification quality and community support by looking for running code. I oppose even more this part of the definition of running code: The minimum rights that should be granted for this source code are the right to duplicate it for purpose of reading it and the right to execute it or generate the binary code to execute it. I spend nearly all my time and energy these days on open source software, so this would not be a barrier for me, but it would be for many people whose contributions are important. It seems that there is a general misunderstanding that this draft asks for mandatory source implementation. I have seen no evidence of any such misunderstanding. It certainly isn't what Scott objected to above. This is not the case, and this will be better explained in the next version of the draft. What this draft ask for is to be mandatory to list in a specific section the names, authors and sponsors of early implementations available in source form. And that's the problem Scott is referring to, and which I agree is a significant issue. There is no doubt that the process of implementing something provides valuable insight into specification clarity, general implementabiity, and protocol complexity. But the same insights accrue from *any* implementation, irrespective of whether it is done as open source or not. The only advantage an open source implementation has over closed source is that others can look at it. But while this advantage is real, the bias it could create in favor of open source as a means of assessing protocols is just not worth it. The proposal never asked for open source implementations. [...] And I continue to believe the costs are far greater than the benefits. OK. -- Marc Petit-Huguenin Home: m...@petit-huguenin.org Work: petit...@acm.org ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Running Code
Cullen Jennings wrote: On Mar 3, 2009, at 3:43 PM, Marc Petit-Huguenin wrote: Giving to early implementers a guaranty that their contributions will not be forgotten is a way to counterbalance the time and effort spent in working on this contributions. Marc, I feel that it is well worth thanking anyone in the acknowledgements that does a full or significant early implementation and sends comments to the list about it. Even if that comment is we found no problems with the spec. It is a huge amount of work to test a spec by implementing it and a valuable contribution to the development. If you, or others, see any RAI Area WG drafts that should really acknowledge an implementation, please bring it to my attention. I suspect that many people at IETF would feel it is worth saying thanks for this kind of work, I'd encourage implementors to bring it up with WG draft editors and Chairs if they think someone should be added to the Acknowledgements section. Thanks, Cullen RAI AD PS - Thank you for your TURN implementations - as you know, they have helped find many problems with that spec. I'm off to read the TURN Acknowledgements :-) My contributions were acknowledged, it's not the issue. The issue, IMO, is that there is not enough early implementations and I was just trying to find a way to improve this. The solution proposed was universally rejected, so the problem is still here. -- Marc Petit-Huguenin Home: m...@petit-huguenin.org Work: petit...@acm.org ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Passing of Jim Bound
Russ Housley wrote: This is very sad news. Jim was a very strong supporter of the IETF and IPv6. Very much a loss. Quite a colorful personality. I will never forget his mike time at the Danver's IETF in his 'nam fatigues. When he wanted to make a point, he did not pull any punches. And the few times he was shown his was not the position that was going to move forward, he got with everyone else and made things happen. Jim served the community as: - IPv6 Forum Chief Technology Officer - Chair of the North American IPv6 Task Force - Active IETF contributor, including member of the IPng Directorate We will miss him. Russ --- forwarded message --- From: Pouffary, Yanick yanick.pouff...@hp.com Date: March 3, 2009 8:23:07 AM EST To: nav...@ipv6forum.com, memb...@ipv6forum.com Subject: Jim Bound Dear IPv6-ers, Jim Bound passed away yesterday. Jim was only 58 years old. Jim was a symbol of integrity and professionalism. He made a profound impact on our industry and everyone who worked with him. I am very fortunate to have been able to also call Jim friend. Very very sad time, Yanick ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Consensus Call for draft-housley-tls-authz
--On Friday, March 06, 2009 14:08 -0800 Kurt Zeilenga kurt.zeile...@isode.com wrote: ... Okay, so we're being overly anal here. Like we can control the world of protocol extensions. Kurt, While I agree (and strongly so), there is lots of precedent for the IESG rejecting parameter registrations because of distaste for a particular extension, presumably in the hope that no registered value will imply the unpopular extension idea goes away. There are indeed lots of precedents for this. And speaking as someone who, as media types reviewer, has had had to clean up the mess as best I could when we were overly restrictive with one of these things, there is also precedent that doing this can be a REALLY bad idea. From a process standpoint, there is no difference between we won't let you have a value because there are identified serious technical flaws and risks with the extension and the IESG finds you and/or your proposal unattractive and cannot determine that there is community consensus to the contrary, so you don't get the value. Exactly so. Of course, if the requester is at all determined, denying the value assignment rarely works. Instead, it leads to squatting on parameter values which, in any sort of limited space, is a sure path to interoperability problems with applications that use the values differently and may have registered them. And in the case of a large space, the registry ends up being incomplete, thereby diminishing its value. If the unregistered value ends up getting deployed, the lack of registry information, including but not limited to security considerations, can lead to operational problems. And depending on the shape of the parameter space there can still be collisions leading to interop problems. And that is probably just a long way of saying like we can control But in believing we can we can things even worse. Ned ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Consensus Call for draft-housley-tls-authz
While I agree (and strongly so), there is lots of precedent for the IESG rejecting parameter registrations because of distaste for a particular extension, presumably in the hope that no registered value will imply the unpopular extension idea goes away. There are indeed lots of precedents for this. And speaking as someone who, as media types reviewer, has had had to clean up the mess as best I could when we were overly restrictive with one of these things, there is also precedent that doing this can be a REALLY bad idea. I agree with Ned. The main purpose of the registry should be to document what is out there, not to act as a gatekeeper. Even when a protocol is not a full standard, having a public documentation is useful. Documentation enables filtering, monitoring, even debugging. By the way, other institutions have found ways to decouple number collision avoidance and registration. IETF protocols use short fields for parameter identifiers, small number spaces that effectively mandate registration in order to avoid collisions. This is an engineering decision that trades administrative hassles for shorter messages. It is not the only choice. Other design have used Object Identifiers (SNMP, ASN.1), or Universal Resource Locators (most W3C protocols). OID and URL requires some amount of registration, to obtain a node in the hierarchy, but allow for decentralized allocation of identifiers in these hierarchies. If you don't want to use a hierarchy, you can also use GUID, essentially a 128 bit random number. Open extensibility with OID, URL or GUID is, in my opinion, a better design than relying on registries for number allocations. -- Christian Huitema ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Consensus Call for draft-housley-tls-authz
Hi, On Mar 7, 2009, at 5:38 PM, Christian Huitema wrote: I agree with Ned. The main purpose of the registry should be to document what is out there, not to act as a gatekeeper. Even when a protocol is not a full standard, having a public documentation is useful. Documentation enables filtering, monitoring, even debugging. This is not how IANA staff have been directed to maintain the IETF registries. Regards, -drc ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Consensus Call for draft-housley-tls-authz
On Sat, 7 Mar 2009 17:49:54 -1000 David Conrad d...@virtualized.org wrote: Hi, On Mar 7, 2009, at 5:38 PM, Christian Huitema wrote: I agree with Ned. The main purpose of the registry should be to document what is out there, not to act as a gatekeeper. Even when a protocol is not a full standard, having a public documentation is useful. Documentation enables filtering, monitoring, even debugging. This is not how IANA staff have been directed to maintain the IETF registries. That is not how IANA staff has been directed to maintain *some* IETF registries. Typically, the RFC that creates a registry specifies the conditions for it. It may be IETF consensus, or a whole host of other options; see RFC 5226 for more details. The issue here is two-fold: what are the specified conditions for this particular registry, and was the decision of the TLS WG correct when it specified them? Christian's note suggests other code point design strategies that don't run into the limited number of small integers problem. Very true -- and those strategies are explicitly recognized by 5226. There may be a problem here, but it's not the general IANA problem, it's the specific decision made once upon a time. --Steve Bellovin, http://www.cs.columbia.edu/~smb ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Abstract on Page 1?
At 14:02 07/03/2009, Henrik Levkowetz wrote: On 2009-03-04 16:33 Margaret Wasserman said the following: I would like to propose that we re-format Internet-Drafts such that the boilerplate (status and copyright) is moved to the back of the draft, and the abstract moves up to page 1. I don't believe that there are any legal implications to moving our IPR information to the back of the document, and it would be great not to have to page down at the beginning of every I-D to skip over it. If someone wants to check the licensing details, they could look at the end of the document. +1 Whether or not this is an easy fix for the tools, I think it's the right thing to do, not only for drafts but also for RFCs, as it lets us focus on the technical matter of a document, rather than copyright, other IPR details, and administrivia. Hear hear, IFF we need copyright on page 1 something like this should be sufficient: This document is covered by IETF Copyright policy ID, copy of this policy can be found at the end of the document Or: s/at the end of the document/at http://www.ietf.org/copyright_ID/ I have no comment on what form the ID part should take other than it MUST be shorter than 30 characters. Olafur ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Passing of Jim Bound
- Robert Moskowitz rgm-i...@htt-consult.com wrote: Very much a loss. Quite a colorful personality. I will never forget his mike time at the Danver's IETF in his 'nam fatigues. And neither will I (as the person he was flaming!). That said, I am truly saddened by his passing. His wit was sharp and his heart was always in the right place. I will miss him. -Jeff -- Jeffrey I. Schiller MIT Network Manager Information Services and Technology Massachusetts Institute of Technology 77 Massachusetts Avenue Room W92-190 Cambridge, MA 02139-4307 617.253.0161 - Voice j...@mit.edu smime.p7s Description: S/MIME Cryptographic Signature ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Consensus Call for draft-housley-tls-authz
--On Saturday, March 07, 2009 12:31 -0500 Richard M Stallman r...@gnu.org wrote: So the answer to your question is that Experimental RFCs are different from Standards Track ones because, among other things, there is no implicit IETF recommendation of implementation and deployment of the technology and because part of the purpose of publication is educational. If a proposed standard is not freely implementable, in general it should not be accorded any status beyond a mere proposal. But an experimental RFC is not a Proposed Standard, a proposed standard, a document that is in the process of being considered for standardization, or any other sort of standard or prestandard. ... john ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
