Re: Colloquial language [Re: Last Call: (The Tao of IETF: A Novice's Guide to the Internet Engineering Task Force) to Informational RFC]
On 5/31/2012 8:36 AM, Brian E Carpenter wrote: Have we any evidence that this is a problem for the community? The informal style is one of the virtues of the Tao. I'd be sorry to lose it. Let's separate use of colloquial language from overall writing style. It is possible to write in an informal style without using colloquialisms. I could, for example, insert some side comment here that would be informal and lack colloquialisms. By some measures, the preceding sentence is an example of exactly that... Colloquialisms are well known to impede understanding by non-native English speakers. So, do you have any evidence that this is /not/ a problem for that part of our community? d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net
Colloquial language [Re: Last Call: (The Tao of IETF: A Novice's Guide to the Internet Engineering Task Force) to Informational RFC]
On 2012-05-31 02:49, Peter Saint-Andre wrote: > Overall I continue to think that this is a helpful document, as were its > predecessors. > > That said, I would assume that many potential readers of this document > are not native English speakers. Thus I suggest that the more colloquial > words and phrases might best be changed to more standard English. Have we any evidence that this is a problem for the community? The informal style is one of the virtues of the Tao. I'd be sorry to lose it. Maybe we can ask some of the people concerned, such as recent presenters of the Newcomers tutorial in languages other than English. Brian
Mission statement [Re: Last Call: (The Tao of IETF: A Novice's Guide to the Internet Engineering Task Force) to Informational RFC]
On 2012-05-31 07:22, Eliot Lear wrote: ... > * I've been told by some that the Mission of the IETF is in some way > out of date. I don't know whether this is true, That sound like somebody's personal opinion, but it is still a BCP and therefore still represents IETF consensus. > but if it is, the > reference should be removed. I don't think so. Brian
Re: Last Call: (The Tao of IETF: A Novice's Guide to the Internet Engineering Task Force) to Informational RFC
Hi, I agree with much of what Peter Saint-Andre wrote. In addition I suggest the following changes: * I've been told by some that the Mission of the IETF is in some way out of date. I don't know whether this is true, but if it is, the reference should be removed. * 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 don't know about anyone else, but my experience has changed with regard to there being a "fair amount of time for socializing". I would say there is a modest amount of time for socializing. * 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. * The last paragraph in Section 4 is outdated. Everyone uses wireless these days– everywhere at nearly every meeting. * 4.12 really should be a top level section (moved further back). * Section 5 (Working Groups) really should be moved forward (after Section 3 but before what is now Section 4). * Move acknowledgments to the back. As it stands that text forms a disconnect between the Intro and later sections. Finally I have been told that the Tao is meant to be a living document, e.g., a wiki. Is that now not to be the case? Eliot On 5/31/12 12:56 AM, The IESG wrote: > The IESG has received a request from an individual submitter to consider > the following document: > - 'The Tao of IETF: A Novice's Guide to the Internet Engineering Task >Force' >as Informational RFC > > The Tao of the IETF has grown a bit stale. For example, many of the > tasks that were requested by email are now done with online tools, > completely avoiding manual intervention by the Secretariat. This is > an effort to refresh the document. > > 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-06-27. 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 > >This document describes the inner workings of IETF meetings and >Working Groups, discusses organizations related to the IETF, and >introduces the standards process. It is not a formal IETF process >document but instead an informational overview. > > The file can be obtained via > http://datatracker.ietf.org/doc/draft-hoffman-tao4677bis/ > > IESG discussion can be tracked via > http://datatracker.ietf.org/doc/draft-hoffman-tao4677bis/ballot/ > > No IPR declarations have been submitted directly on this I-D. > > > >
Re: Last Call: (The Tao of IETF: A Novice's Guide to the Internet Engineering Task Force) to Informational RFC
Overall I continue to think that this is a helpful document, as were its predecessors. That said, I would assume that many potential readers of this document are not native English speakers. Thus I suggest that the more colloquial words and phrases might best be changed to more standard English. Naturally one can quibble about particulars, but here are some examples as I see them: "get into the swing of things" "give them a warm, fuzzy feeling" "happenings" "unsung heroes" "home base" "pet project" "pet peeve" "leaps and bounds" "get technical" "discussions of cosmic significance" "gatherings of the tribes" "kicks in" "breath of fresh air" "big-name" "take the pluge" I realize that such words and phrases lend a friendly tone to the document, but IMHO that friendliness will be lost on non-native speakers. Peter -- Peter Saint-Andre https://stpeter.im/
last call comments on draft-ietf-krb-wg-kdc-model
--- Begin Message --- Topics: [Ietf-krb-wg] Add. comments on Kdc model, WAS[Re: I-D Action: draft-ietf-krb-wg-kdc-model-12.txt] Re: [Ietf-krb-wg] I-D Action: draft-ietf-krb-wg-kdc-model-12.txt --- End Message --- --- Begin Message --- I have additional comments. These following 3 attribute definitions bind the implementer to a very special way to address counting failed authentication attempts. 4.1.1.5. principalNumberOfFailedAuthenticationAttempts This single-valued integer attribute contains a count of the number of times an authentication attempt was unsuccessful for this Principal. Implementations SHOULD NOT allow this counter to be reset. 4.1.1.6. principalLastFailedAuthentication This single-valued attribute contains the time and date for the last failed authentication attempt for this Principal. The syntax of the attribute MUST be Internet Date/Time Format from [RFC3339]. 4.1.1.7. principalLastSuccessfulAuthentication This single-valued attribute contains the time and date for the last successful authentication attempt for this principal. The syntax of the attribute MUST be Internet Date/Time Format from [RFC3339].\ They force a mechanism where you have a specific counter. It seems to prevent instead an implementation that may have a multi-valued attribute where all failed attempts are recorded in order to have an audit trail, and the number of failed attempts is computed by counting these values. However assuming that this scheme is really preferred, then I do not understand how it can be implemented if 4.1.1.5 says that the counter should not be reset. I think implementations need to reset it when a successful authentication happens. I think that should be explicitly said, rather than a blanket 'SHOULD NOT reset'. I would like to make 4.1.1.8, 4.1.1.9 a SHOULD, not a MUST The way 4.1.1.10 is worded makes it impossible to reuse the modifyTimestamp attribute normally present in LDAP directories, as Kerberos implementations cannot force the directory not to update the timestamp on credential changes, so please drop the exclusion, I do not see what's the point anyways. In 4.2, it is unclear what 'MUST facilitate, to the extent possible, an administrator's ability to place more restrictive access controls ...' will end up being interpreted. How do you measure if an implementation complies with this mandate ? I am not sure I understand 4.3. 4.3.1.5 and 4.3.1.6 are not consistent with the rest of the document about how the date format is mandated. (Will need to be fixed to whatever we decide after discussion about date format I opened in a separate thread) Also keyNotUsedBefore keyNotUsedAfter keyIsDisabled are not something normally associated to key attributes today generally they are associated to keysets, is there a MUST implied in these having to be available per key, and not per keyset ? I find the part on policy a bit hand-wavy, what is the point of identifying specific, yet undefined, policies with OIDs if they are opaque in the end ? Simo. -- Simo Sorce * Red Hat, Inc * New York ___ ietf-krb-wg mailing list ietf-krb...@lists.anl.gov https://lists.anl.gov/mailman/listinfo/ietf-krb-wg --- End Message --- --- Begin Message --- On Wed, 2012-05-30 at 13:00 -0400, Sam Hartman wrote: > I'd like to call the working group's attention to the new text > surrounding RFc 2119 language. In particular in this draft, MUST > features in the information model MUST be representable in schema *and* > MUST be supported by all implementations of the information model. That > last was intended by Leif but was new to me. Thanks for bringing this up Sam. I am reading the doc now and I have a question as to why we have a MUST on the syntax of attributes like principalNotUsedBefore. It says it MUST use "Internet Date/Time Format from [RFC3339]" This is problematic as LDAP uses generalizedTime defined in RFC4517. It is a representation of ISO8061 just like RFC3339, but a *different* representation. Trying to force all implementations to use the RFC3339 definition seem wrong. What implementation, today, uses RFC3339 ? I would rather suggest that the document does not mandate the specific representation discussed in RFC3339 but allow any ISO8601 based representation. If it is felt that one representation really needs to be chosen then I'd ask to use the generalizedTime representation as defined by RFC4517 instead of the one in RFC3339. Simo. -- Simo Sorce * Red Hat, Inc * New York --- End Message ---
Re: [Ietf-krb-wg] Add. comments on Kdc model, WAS[Re: I-D Action: draft-ietf-krb-wg-kdc-model-12.txt]
[I'm going to forward Simo's original comments to the IETF list because this doc is in IETF last call. Here are my responses as chair. ] > "Simo" == Simo Sorce writes: Simo> 4.1.1.5. principalNumberOfFailedAuthenticationAttempts Simo>This single-valued integer attribute contains a count of Simo> the number of times an authentication attempt was unsuccessful Simo> for this Principal. Implementations SHOULD NOT allow this Simo> counter to be reset. [. . .] Simo> They force a mechanism where you have a specific counter. It Simo> seems to prevent instead an implementation that may have a Simo> multi-valued attribute where all failed attempts are recorded Simo> in order to have an audit trail, and the number of failed Simo> attempts is computed by counting these values. I think you'd also need to record last successful authentication. However, given last successful authentication and a set of failed authentications I think it's quite easy to give an algorithm for producing count of failed authentications and last failed authentication. It does mean that to increment the count of failed authentications you need to decide on a time for the list of failed authentications. I think that's consistent with the information model though. Simo> However assuming that this scheme is really preferred, then I Simo> do not understand how it can be implemented if 4.1.1.5 says Simo> that the counter should not be reset. I think implementations Simo> need to reset it when a successful authentication happens. I Simo> think that should be explicitly said, rather than a blanket Simo> 'SHOULD NOT reset'. There was WG discussion on this. The text really means the count should be non-decreasing. This makes it impossible to implement a policy like 2 failed auths since the last successful auth. With my chair hat on, my reading of the discussion is that we really do mean what the text says. However, I don't think the point about being unable to track number of failed auths since last successful auth has been brought up before and that point is sufficient to reopen the discussion.
RE: New Maillist for the discussion on the Management of Constrained Networks and Devices
Hi All, as noted in the maillist announcement of IETF secretary "coma" maillist is for the discussion on the management of constrained networks and devices. The mailing list will discuss and identify the issues and requirements and objectives for the management of devices in such an environment with a special focus on and differentiation of device classes. The idea and trigger for the maillist creation came from a discussion in the OPS directorate during IETF #82. As draft-ietf-opsawg-management-stds-07 states IETF so far has not developed specific technologies for the management of constrained networks. OPS directorate members stated in IETF #82 that there is a need to understand the requirements and the necessary solutions for the management of such a constrained network and its devices. The assumption people had was that we need a comprehensive management approach to be able to address the diverse needs of different device classes. Although the OPS area was doing already standardization work for network management, the Core WG is one of the essential WGs at IETF interested in the management of constrained devices. Following are some of the questions which have been raised in the OPS directorate meeting, which are for sure subject to extend from Core WG pov.: * Do we need a new development for IoT management (i.e. constrained devices) at all? - If yes, what is really needed as standard and what is an overkill? * What type of devices can we support? * How are the classes 0-2 for constrained devices defined in detail? * Is some simple configuration management already sufficient? - Or do we need also a simple fault management and monitoring? * What type of data model modules do we need to standardize? - Just a few core models like ip-cfg, interface? - or also other specific models for monitoring? * Can we use available management standards and data models as a starting point and simplify them? * Concerning the encoding (JSON, XML, or binary) we seem to be flexible with tools. - Concerning a normative data modeling language, we need to choose a suitable language capable to prepare structured models. - Is JSON sufficient for this purpose, or should YANG or any other modeling language be used? * What is appropriate as message transport? - CoAP over UDP with soft-transactions? - Netconf-Light over TCP? Obviously the list of the questions above is not exhaustive. Carsten kindfully provided already in the Prague meeting the definition of device classes 0-2 (http://www.ietf.org/proceedings/80/slides/core-0.pdf). I think it would be useful to start a discussion first on the detailed definition of these device classes 0-2 in constrained networks and based on their capabilities which functionality they will be able to support. This can be then used as a guideline for further discussion on the requirements or objectives for management of such devices. As noted in the announcement the result of the coma discussion can lead to a taxonomy document and a problem statement highlighting the need for new work. Please send your opinions/comments to the coma maillist (c...@ietf.org). To subscribe pls go to: https://www.ietf.org/mailman/listinfo/coma Cheers, Mehmet BTW: Coma has been chosen as the maillist name following the definition below: Coma \Co"ma\, n. [L., hair, fr. Gr. ko`mh.] 1. (Astron.) The envelope of a comet; a nebulous covering, which surrounds the nucleus or body of a comet. [1913 Webster]
new mailing list for discussing ABNF issues
Folks, Periodically someone wants to ask a question about ABNF, suggest an enhancement or otherwise exchange views about ABNF. There has not been an obvious forum for this. This sometimes means that Paul Overell and I get queried, as authors of the relevant RFC. For quick items, that's fine, but sometimes the issues are more substantive. So we've set up: abnf-disc...@ietf.org For public discussion of the meta-language. Subscribe at: https://www.ietf.org/mailman/listinfo/abnf-discuss There will also be a web page to hold listings of tools and other relevant materials. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net
RE: Last Call: (Guidelines for DefiningExtensions to IODEF) to Informational RFC
Hi, The inclusion of the template as an Appendix in the document is confusing - right now A.1 through A.7 define sections in the future I-Ds, while A.8 and A.9 describe appendices in the future I-D. This document has two sections each titled Appendix A and Appendix B. Moreover, this inclusion has the disadvantage that if changes or updates need to be brought up for reasons whatsoever, a new RFC needs to be written. Did the author and the WG considered adopting the approach taken by RFC 5249 which located the templates under the IETF tools web pages and only referred them from the RFC? Regards, Dan > -Original Message- > From: ietf-announce-boun...@ietf.org [mailto:ietf-announce- > boun...@ietf.org] On Behalf Of The IESG > Sent: Thursday, May 17, 2012 12:53 AM > To: IETF-Announce > Cc: m...@ietf.org > Subject: Last Call: (Guidelines for > DefiningExtensions to IODEF) to Informational RFC > > > The IESG has received a request from the Managed Incident Lightweight > Exchange WG (mile) to consider the following document: > - 'Guidelines for Defining Extensions to IODEF' >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-30. 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 > > >This document provides guidelines for extensions to IODEF [RFC5070] >for exchange of incident management data, and contains a template > for >Internet-Drafts describing those extensions, in order to ease the >work and improve the quality of extension descriptions. > > > > > The file can be obtained via > http://datatracker.ietf.org/doc/draft-ietf-mile-template/ > > IESG discussion can be tracked via > http://datatracker.ietf.org/doc/draft-ietf-mile-template/ballot/ > > > No IPR declarations have been submitted directly on this I-D. >
