Re: author's address (was: Re: Fwd: [OPS-DIR] OPS-DIR Reviewofdraft-yevstifeyev-tn3270-uri-12)
I wrote: I [...] edited both RFC 4645 and 5646 as "Consultant." s/5646/5645/ -- Doug Ewell | Thornton, Colorado, USA | http://www.ewellic.org RFC 5645, 4645, UTN #14 | ietf-languages @ is dot gd slash 2kf0s ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: author's address (was: Re: Fwd: [OPS-DIR] OPS-DIR Review ofdraft-yevstifeyev-tn3270-uri-12)
Peter Saint-Andre wrote:
For what it's worth, Section 10 of the informational RFC 2223
("Instructions to RFC Authors") states:
Each RFC must have at the very end a section giving the author's
address, including the name and postal address, the telephone number,
(optional: a FAX number) and the Internet email address.
The Internet is not the type of chummy small-town environment where we
can trust just anybody with our home address and phone number, or our
bank account and credit card numbers, and where we can leave our front
doors unlocked at night.
I worked on two I-Ds in a WG where participant A once responded to
participant B's support of an RFC 3683 P-R action against A by
contacting B's employer, gleaned from his e-mail address, demanding that
the employer take professional action against B. In this type of
hostile environment, I declined to state my employer's name or post to
the WG list from my work address, much less divulge other personal
information, and edited both RFC 4645 and 5646 as "Consultant."
The argument that personal information is necessary to distinguish the
author from other people with the same name probably carries some weight
for authors named "John Smith" or "Bob Miller." There are few enough
people named "Doug Ewell" in the world that the risk of ambiguity of
authorship seems much more remote than the risk to personal security if
too much personal information is provided. I suspect the same is true
for people named "Mykyta Yevstifeyev."
Having said that, I don't think there is any precedent for I-D authors
or editors to claim their document was written by "IETF" or "IESG," and
I doubt this will be permitted.
--
Doug Ewell | Thornton, Colorado, USA | http://www.ewellic.org
RFC 5645, 4645, UTN #14 | ietf-languages @ is dot gd slash 2kf0s
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
Weekly posting summary for ietf@ietf.org
Total of 113 messages in the last 7 days. script run at: Fri Jan 14 00:53:02 EST 2011 Messages | Bytes| Who +--++--+ 0.88% |1 | 35.69% | 447080 | f...@cisco.com 9.73% | 11 | 4.45% |55771 | julian.resc...@gmx.de 5.31% |6 | 3.68% |46098 | hannes.tschofe...@gmx.net 5.31% |6 | 3.54% |44394 | evniki...@gmail.com 5.31% |6 | 2.82% |35297 | t...@americafree.tv 4.42% |5 | 2.58% |32259 | john-i...@jck.com 4.42% |5 | 2.46% |30757 | daedu...@btconnect.com 3.54% |4 | 3.25% |40724 | li...@cs.ucla.edu 2.65% |3 | 3.30% |41392 | hal...@gmail.com 3.54% |4 | 1.59% |19924 | y...@checkpoint.com 2.65% |3 | 1.64% |20599 | s...@resistor.net 1.77% |2 | 2.33% |29148 | b...@nostrum.com 2.65% |3 | 1.10% |13813 | d...@dcrocker.net 2.65% |3 | 1.08% |13513 | d...@ewellic.org 1.77% |2 | 1.75% |21975 | flu...@cisco.com 1.77% |2 | 1.03% |12934 | h...@ripe.net 1.77% |2 | 1.02% |12837 | d3e...@gmail.com 1.77% |2 | 1.02% |12814 | j...@joelhalpern.com 1.77% |2 | 0.99% |12388 | bob.hin...@gmail.com 1.77% |2 | 0.96% |12026 | ves...@tana.it 1.77% |2 | 0.96% |12020 | joe...@bogus.com 1.77% |2 | 0.90% |11228 | adrian.far...@huawei.com 1.77% |2 | 0.86% |10808 | jdfalk-li...@cybernothing.org 1.77% |2 | 0.81% |10137 | randy_pres...@mindspring.com 0.88% |1 | 1.59% |19881 | tobias.gond...@gondrom.org 0.88% |1 | 1.29% |16187 | ebur...@standardstrack.com 0.88% |1 | 1.11% |13937 | stpe...@stpeter.im 0.88% |1 | 1.09% |13706 | william.p...@nist.gov 0.88% |1 | 0.88% |11040 | lars.egg...@nokia.com 0.88% |1 | 0.87% |10920 | md3...@att.com 0.88% |1 | 0.85% |10686 | msraje...@gmail.com 0.88% |1 | 0.72% | 8963 | rich...@shockey.us 0.88% |1 | 0.72% | 8958 | mstjo...@comcast.net 0.88% |1 | 0.68% | 8528 | krishnabi...@gmail.com 0.88% |1 | 0.67% | 8390 | nar...@us.ibm.com 0.88% |1 | 0.63% | 7850 | ty...@mit.edu 0.88% |1 | 0.62% | 7809 | pek...@netcore.fi 0.88% |1 | 0.62% | 7729 | mehmet.er...@nsn.com 0.88% |1 | 0.61% | 7654 | dy...@voxeo.com 0.88% |1 | 0.57% | 7151 | framefri...@gmail.com 0.88% |1 | 0.54% | 6791 | elw...@dial.pipex.com 0.88% |1 | 0.54% | 6759 | spen...@wonderhamster.org 0.88% |1 | 0.53% | 6634 | rja.li...@gmail.com 0.88% |1 | 0.52% | 6510 | s...@venaas.com 0.88% |1 | 0.47% | 5870 | huit...@microsoft.com 0.88% |1 | 0.47% | 5848 | o...@cisco.com 0.88% |1 | 0.46% | 5734 | l...@pi.nu 0.88% |1 | 0.45% | 5579 | l...@cisco.com 0.88% |1 | 0.42% | 5241 | michelle.cot...@icann.org 0.88% |1 | 0.41% | 5134 | dwor...@avaya.com 0.88% |1 | 0.40% | 5044 | bidul...@openss7.org 0.88% |1 | 0.39% | 4857 | hannes.tschofe...@nsn.com 0.88% |1 | 0.37% | 4667 | ero...@cisco.com 0.88% |1 | 0.35% | 4395 | a...@shinkuro.com 0.88% |1 | 0.35% | 4353 | john-l...@jck.com +--++--+ 100.00% | 113 |100.00% | 1252741 | Total ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Increasing character limit for registration in internet domain names: 76 or 68 or 91 or 83 or 64 higher the better
Too many applications have the existing DNS segment lengths encoded. I suggest that you instead consider. hare.krishna.hare.krishna.krishna.krishna.hare.hare.hare.rama.hare.ramarama.rama.hare.hare You would have to talk to ICANN to get the .hare TLD assigned. On Thu, Jan 13, 2011 at 6:45 PM, Krishna Birth wrote: > (please view this email with UTF-8 enabled on your viewer) > > This is a request for internet engineers to increase the character limit > for registration in the various internet domain names (com, net, org, info > etc) from 63 characters to more at least 76 or 68 or 91 or 83 or 64, the > higher it is the better. I believe the raising the characters on the > internet domain names will very good from a spiritual perspective. I base > these figures on the spiritual prayer and chant: > > harekrishnaharekrishnakrishnakrishnahareharehareramahareramaramaramaharehare > = 76 characters > > harekrsnaharekrsnakrsnakrsnahareharehareramahareramaramaramaharehare = 68 > characters > > hare-krishna-hare-krishna-krishna-krishna-hare-hare-hare-rama-hare-rama-rama-rama-hare-hare > = 91 characters > > hare-krsna-hare-krsna-krsna-krsna-hare-hare-hare-rama-hare-rama-rama-rama-hare-hare > = 83 characters > > harekrsnaharekrsnakrsnakrsnahareharehareramhareramramramharehare = 64 > characters > > > It would allow the Hare कrishna Mahamantra, the great prayer for > deliverance in this Age to be fully put on an internet domain name. The > chanting and recitation of the Mahamantra cleanses the heart of the > impurities and pollution. Caitanya Mahaprabhu and incarnation of कrishna, > the Supreme Personality of Godhead Movement, popularised the chanting of the > Mahamantra some 500 years ago and is meant for every town and village in the > world. > > Now His Divine Grace A C Bhaकtivedanta Swami Prabhupada, Founder, Eternal > Diकsa and Siकsa Spiritual Master of the Hare कrishna Movement in the chain > of disciplic succession has popularised it in the West and continues to > popularise. > > > p.s. Some time ago I posted on the IETF mailing list via another email > account. > > > Best, > > > Meeकu > ___ > Ietf mailing list > Ietf@ietf.org > https://www.ietf.org/mailman/listinfo/ietf > > -- Website: http://hallambaker.com/ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Increasing character limit for registration in internet domain names: 76 or 68 or 91 or 83 or 64 higher the better
(please view this email with UTF-8 enabled on your viewer) This is a request for internet engineers to increase the character limit for registration in the various internet domain names (com, net, org, info etc) from 63 characters to more at least 76 or 68 or 91 or 83 or 64, the higher it is the better. I believe the raising the characters on the internet domain names will very good from a spiritual perspective. I base these figures on the spiritual prayer and chant: harekrishnaharekrishnakrishnakrishnahareharehareramahareramaramaramaharehare = 76 characters harekrsnaharekrsnakrsnakrsnahareharehareramahareramaramaramaharehare = 68 characters hare-krishna-hare-krishna-krishna-krishna-hare-hare-hare-rama-hare-rama-rama-rama-hare-hare = 91 characters hare-krsna-hare-krsna-krsna-krsna-hare-hare-hare-rama-hare-rama-rama-rama-hare-hare = 83 characters harekrsnaharekrsnakrsnakrsnahareharehareramhareramramramharehare = 64 characters It would allow the Hare कrishna Mahamantra, the great prayer for deliverance in this Age to be fully put on an internet domain name. The chanting and recitation of the Mahamantra cleanses the heart of the impurities and pollution. Caitanya Mahaprabhu and incarnation of कrishna, the Supreme Personality of Godhead Movement, popularised the chanting of the Mahamantra some 500 years ago and is meant for every town and village in the world. Now His Divine Grace A C Bhaकtivedanta Swami Prabhupada, Founder, Eternal Diकsa and Siकsa Spiritual Master of the Hare कrishna Movement in the chain of disciplic succession has popularised it in the West and continues to popularise. p.s. Some time ago I posted on the IETF mailing list via another email account. Best, Meeकu ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Feedback on Day Passes
On Nov 29, 2010, at 11:39 AM, Tobias Gondrom wrote: > Bob, > > agree with James request for more detail on the used day passes, if > possible. > > Personally, I believe the risen cost for day passes probably knocked out > some of the demand (basic supply-demand curve from economics ;-) ). > Probably day passes are more attractive to local participants who want > to get a taste of the IETF or only visit one WG session. I you want to get a taste of IETF, you can do it for free. You join ISOC, which is free, then as an ISOC member you can come to IETF for free on the tuesday of any IETF meeting. You might not be able to go to the WG meeting you want if it is not on tuesday, but you can get a taste of IETF. I think this is a good thing and have encouraged people to do it - it's how we get new people to IETF. I know there are some people that disagree with me because it basically results in tourists at the meetings. So far the number people doing this is so low that it is not a problem. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call on draft-ietf-pim-registry-03.txt
On 13.01.2011 21:43, Michelle Cotton wrote: Many believe it makes it very clear to the users of the registry what is available for assignment. Something we will be rolling out soon (for those registries with a finite space) will be small charts showing how much of the registry space is unassigned, assigned and reserved (utilizing the unassigned entries). --Michelle ... Exactly my point -- we should distinguish between the actual registry contents (assigned / reserved), and how it's presented. Best regards, Julian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call on draft-ietf-pim-registry-03.txt
Many believe it makes it very clear to the users of the registry what is available for assignment. Something we will be rolling out soon (for those registries with a finite space) will be small charts showing how much of the registry space is unassigned, assigned and reserved (utilizing the unassigned entries). --Michelle On 1/12/11 6:35 AM, "Julian Reschke" wrote: > On 12.01.2011 15:22, Adrian Farrel wrote: >> Entirely at random I clicked on: >> >> http://www.iana.org/assignments/aaa-parameters/aaa-parameters.xhtml >> http://www.iana.org/assignments/calipso/calipso.xhtml >> http://www.iana.org/assignments/lmp-parameters >> >> Looks like IANA tries to fill up all the blanks with markers of "unassigned". >> >> Is that harmful? > > Minimally, it's redundant. Also, it only makes sense on certain types of > registries. > > I just checked the XML version of the first registry, and, indeed, it > contains entries for unassigned values. /me shakes head in disbelief. > > What *should* be done is computing the unassigned ranges for > *presentation*; that is, they should not be part of the actual registry. > The way it's done currently defeats one of the reasons of having a > machine-readable registry (consumers will have to hard-wire knowledge of > the specific "unassigned" entry to make sense of the registry). > > Best regards, Julian > > ___ > 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
author's address (was: Re: Fwd: [OPS-DIR] OPS-DIR Review of draft-yevstifeyev-tn3270-uri-12)
On 1/13/11 10:53 AM, Joel M. Halpern wrote:
> I would also point out that there is a difference between a contact for
> a draft and a contact for a registry.
> For a draft, there is always an individual contact. We frequently
> accept that the only contact information is an email address.
>
> For a registry, the contact information requirement depends upon what
> the update policy is for the registry.
For what it's worth, Section 10 of the informational RFC 2223
("Instructions to RFC Authors") states:
Each RFC must have at the very end a section giving the author's
address, including the name and postal address, the telephone number,
(optional: a FAX number) and the Internet email address.
However, I agree that inclusion of all but the name and email address
has not been enforced.
Peter
--
Peter Saint-Andre
https://stpeter.im/
smime.p7s
Description: S/MIME Cryptographic Signature
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
Re: Fwd: [OPS-DIR] OPS-DIR Review of draft-yevstifeyev-tn3270-uri-12
I would also point out that there is a difference between a contact for a draft and a contact for a registry. For a draft, there is always an individual contact. We frequently accept that the only contact information is an email address. For a registry, the contact information requirement depends upon what the update policy is for the registry. Yours, Joel On 1/13/2011 12:42 PM, Worley, Dale R (Dale) wrote: From: ietf-boun...@ietf.org [ietf-boun...@ietf.org] On Behalf Of Mykyta Yevstifeyev [evniki...@gmail.com] Mentioning my full contact data makes no sense. I can hardly imagine that somebody will come to Ukraine, search Kotovsk (that is rather small town) and than particular street, etc. to ask me about the URI scheme. Those who want that would prefer to contact me by email. ___ In many cases, a person's postal address is more stable and easier to translate into other contact information than the person's e-mail address. Dale ___ 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: Fwd: [OPS-DIR] OPS-DIR Review of draft-yevstifeyev-tn3270-uri-12
I agree with Dale. I have subscriber database of with around 30,000 records and the "churn" in e-mail addresses is much higher than changes in postal information. Of course in (some parts of) the real world, the concept of forwarding, address correction etc exists so that I (sometimes) get notified of the new postal address. In most e-mail cases all I get is a mailer-daemon message. I don't think there is any simple solution to the author contact information problem. Like most things, it will be correct at the time of publication but subject to change in the future. Given that RFCs are archival documents this could only be solved with some large dynamic errata database that nobody is prepared to maintain I am sure. Ole Ole J. Jacobsen Editor and Publisher, The Internet Protocol Journal Cisco Systems Tel: +1 408-527-8972 Mobile: +1 415-370-4628 E-mail: o...@cisco.com URL: http://www.cisco.com/ipj On Thu, 13 Jan 2011, Worley, Dale R (Dale) wrote: > > From: ietf-boun...@ietf.org [ietf-boun...@ietf.org] On Behalf Of > Mykyta Yevstifeyev [evniki...@gmail.com] > > Mentioning my full contact data makes no sense. I can hardly imagine > that somebody will come to Ukraine, search Kotovsk (that is rather small > town) and than particular street, etc. to ask me about the URI scheme. > Those who want that would prefer to contact me by email. > ___ > > In many cases, a person's postal address is more stable and easier > to translate into other contact information than the person's e-mail > address. > > Dale ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Fwd: [OPS-DIR] OPS-DIR Review of draft-yevstifeyev-tn3270-uri-12
From: ietf-boun...@ietf.org [ietf-boun...@ietf.org] On Behalf Of Mykyta Yevstifeyev [evniki...@gmail.com] Mentioning my full contact data makes no sense. I can hardly imagine that somebody will come to Ukraine, search Kotovsk (that is rather small town) and than particular street, etc. to ask me about the URI scheme. Those who want that would prefer to contact me by email. ___ In many cases, a person's postal address is more stable and easier to translate into other contact information than the person's e-mail address. Dale ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Fwd: [OPS-DIR] OPS-DIR Review of draft-yevstifeyev-tn3270-uri-12
> > The reviewer furthermore states, following the rules in > > RFC4395 the document should provide concrete contact information for the > > editor instead of an anonymous email address only. > That would be corrected so that the author will be IETF and contact - IESG. I am not really sure whether this is appropriate. Why are you keen of keeping it more or less anonymous? Cheers, Mehmet > -Original Message- > From: ext Mykyta Yevstifeyev [mailto:evniki...@gmail.com] > Sent: Thursday, January 13, 2011 1:58 AM > To: Ersue, Mehmet (NSN - DE/Munich); IETF Discussion > Subject: Re: Fwd: [OPS-DIR] OPS-DIR Review of draft-yevstifeyev-tn3270- > uri-12 > > 12.01.2011 14:19, Ersue, Mehmet (NSN - DE/Munich) wrote: > > -Original Message- > > From: ops-dir-boun...@ietf.org [mailto:ops-dir-boun...@ietf.org] On > > Behalf Of ext Ersue, Mehmet (NSN - DE/Munich) > > Sent: Wednesday, January 12, 2011 1:07 PM > > To: ops-...@ietf.org > > Cc: draft-yevstifeyev-tn3270-uri-auth...@tools.ietf.org > > Subject: [OPS-DIR] OPS-DIR Review of draft-yevstifeyev-tn3270-uri-12 > > > > I reviewed draft-yevstifeyev-tn3270-uri-12 for its operational > impacts.. > > > > Summary: > > The document gives a specification of syntax, semantics and use of > > 'tn3270' URI scheme. > > > > Obviously this is an individual submission without any document > write-up > > and supporting AD. > Why without? Peter Saint-Andre is sponsoring AD. > > I would like to read a document write-up with the regular template > even > > if it is written by the author. > > > > The main purpose of the document, namely to update the IANA > registration > > of tn3270 URI scheme using the given registration template, should be > > added to the Introduction section. In general I would suggest to > include > > in the Introduction section the purpose of the action and more > > importantly why existing IANA registrations are not sufficient and > why > > the publication of this RFC is needed. > Agreed. I'll add that as soon as possible. > > Obviously the GEN-Area reviewer (Tom Petch) has an opposite opinion > and > > does not see this IANA registration in the interest of IETF (see > > > https://www.ietf.org/ibin/c5i?mid=6&rid=49&gid=0&k1=933&k2=55119&tid=12 > 9 > > 4831574). The reviewer furthermore states, following the rules in > > RFC4395 the document should provide concrete contact information for > the > > editor instead of an anonymous email address only. > That would be corrected so that the author will be IETF and contact - > IESG. > > I don't see any additional operation impact other than above. > > > > Other issues: > > > > - The used language needs some polishing. > > > > - Following are draft nits suggesting correction: > > > > == The copyright year in the IETF Trust and authors Copyright Line > does > > not > > match the current year > > > > -> Use new template or: s/2010/2011/ > Will be corrected. > > -- Obsolete informational reference (is this intentional?): RFC 1738 > > (Obsoleted by RFC 4248, RFC 4266) > > > > -> Use correct reference or clarify. > Obsolete Informational references are allowed. I don't see a problem > here. > > Mykyta > > > > Mehmet > > > > ___ > > OPS-DIR mailing list > > ops-...@ietf.org > > https://www.ietf.org/mailman/listinfo/ops-dir > > ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call on draft-ietf-pim-registry-03.txt
On 13.01.2011 17:14, Mykyta Yevstifeyev wrote: <...> Documents that create a new namespace (or modify the definition of an existing space) and that expect IANA to play a role in maintaining that space (e.g., serving as a repository for registered values) MUST provide clear instructions on details of the namespace. In particular, instructions *MUST* include: <...> 5) Initial assignments and reservations. Clear instructions should be provided to identify any initial assignments or registrations. In addition, any ranges that are to be reserved for "Private Use", "Reserved", **"Unassigned"**, etc. should be *clearly indicated*. <...> Yes. There's still no "MUST" applying to unassigned code points. Note the "In addition" and "should". ... Best regards, Julian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call on draft-ietf-pim-registry-03.txt
13.01.2011 18:10, Julian Reschke wrote: On 13.01.2011 17:08, Mykyta Yevstifeyev wrote: 13.01.2011 17:58, Julian Reschke wrote: On 13.01.2011 16:51, Mykyta Yevstifeyev wrote: ... That sounds like an editorial error to me. "any ranges to be *reserved* for "Unassigned"..." doesn't make any sense at all. They are not reserved. Yes, that is a type of error, but the meaning is that unassigned and reserved values MUST (yes, must, that is in RFC 5226; see citation below) be mentioned. I do not see a citation "below". I meant in the previous message. Please cite where the spec says "must" or "MUST". That is a citation of RFC 5226 <...> Documents that create a new namespace (or modify the definition of an existing space) and that expect IANA to play a role in maintaining that space (e.g., serving as a repository for registered values) MUST provide clear instructions on details of the namespace. In particular, instructions *MUST* include: <...> 5) Initial assignments and reservations. Clear instructions should be provided to identify any initial assignments or registrations. In addition, any ranges that are to be reserved for "Private Use", "Reserved", **"Unassigned"**, etc. should be *clearly indicated*. <...> ... The strings registries are rather exceptions from the rule I cited above. Well, we have many of them. The rules should takes those into account. That, IMO, was the mistake of authors of RFC 5226 that didn't take the text registries into considerations. We have no way to correct that now. ... We can raise errata, and have the authors and the IESG approve them. We can also use common sense, and note that IANA apparently doesn't enforce these rules when they do not make sense. Best regards, Julian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call on draft-ietf-pim-registry-03.txt
On 13.01.2011 17:08, Mykyta Yevstifeyev wrote: 13.01.2011 17:58, Julian Reschke wrote: On 13.01.2011 16:51, Mykyta Yevstifeyev wrote: ... That sounds like an editorial error to me. "any ranges to be *reserved* for "Unassigned"..." doesn't make any sense at all. They are not reserved. Yes, that is a type of error, but the meaning is that unassigned and reserved values MUST (yes, must, that is in RFC 5226; see citation below) be mentioned. I do not see a citation "below". I meant in the previous message. Please cite where the spec says "must" or "MUST". ... The strings registries are rather exceptions from the rule I cited above. Well, we have many of them. The rules should takes those into account. That, IMO, was the mistake of authors of RFC 5226 that didn't take the text registries into considerations. We have no way to correct that now. ... We can raise errata, and have the authors and the IESG approve them. We can also use common sense, and note that IANA apparently doesn't enforce these rules when they do not make sense. Best regards, Julian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call on draft-ietf-pim-registry-03.txt
13.01.2011 17:58, Julian Reschke wrote: On 13.01.2011 16:51, Mykyta Yevstifeyev wrote: ... That sounds like an editorial error to me. "any ranges to be *reserved* for "Unassigned"..." doesn't make any sense at all. They are not reserved. Yes, that is a type of error, but the meaning is that unassigned and reserved values MUST (yes, must, that is in RFC 5226; see citation below) be mentioned. I do not see a citation "below". I meant in the previous message. This should probably be raised as erratum. So the document specifying the regsitry MUST mention what are Unassigned. Moreover, IMO, it would be useful to assign one value for Experimentation. No. should != must. See below. Even further? :-) The same. There are tons of registries where this is not the case; namely all or most of those where the values are strings, not numbers. The strings registries are rather exceptions from the rule I cited above. Well, we have many of them. The rules should takes those into account. That, IMO, was the mistake of authors of RFC 5226 that didn't take the text registries into considerations. We have no way to correct that now. Mykyta Best regards, Julian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call on draft-ietf-pim-registry-03.txt
On 13.01.2011 16:51, Mykyta Yevstifeyev wrote: ... That sounds like an editorial error to me. "any ranges to be *reserved* for "Unassigned"..." doesn't make any sense at all. They are not reserved. Yes, that is a type of error, but the meaning is that unassigned and reserved values MUST (yes, must, that is in RFC 5226; see citation below) be mentioned. I do not see a citation "below". This should probably be raised as erratum. So the document specifying the regsitry MUST mention what are Unassigned. Moreover, IMO, it would be useful to assign one value for Experimentation. No. should != must. See below. Even further? :-) There are tons of registries where this is not the case; namely all or most of those where the values are strings, not numbers. The strings registries are rather exceptions from the rule I cited above. Well, we have many of them. The rules should takes those into account. Best regards, Julian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Fwd: [OPS-DIR] OPS-DIR Review of draft-yevstifeyev-tn3270-uri-12
13.01.2011 13:28, Ersue, Mehmet (NSN - DE/Munich) wrote: The reviewer furthermore states, following the rules in RFC4395 the document should provide concrete contact information for the editor instead of an anonymous email address only. That would be corrected so that the author will be IETF and contact - IESG. I am not really sure whether this is appropriate. Why are you keen of keeping it more or less anonymous? Mehmet, all, Mentioning my full contact data makes no sense. I can hardly imagine that somebody will come to Ukraine, search Kotovsk (that is rather small town) and than particular street, etc. to ask me about the URI scheme. Those who want that would prefer to contact me by email. And nevertheless I'd like the registration template shall contain IETF as author and IESG as contact. That is rather usual for IETF-stream RFCs. All the best, Mykyta Yevstifeyev Cheers, Mehmet -Original Message- From: ext Mykyta Yevstifeyev [mailto:evniki...@gmail.com] Sent: Thursday, January 13, 2011 1:58 AM To: Ersue, Mehmet (NSN - DE/Munich); IETF Discussion Subject: Re: Fwd: [OPS-DIR] OPS-DIR Review of draft-yevstifeyev-tn3270- uri-12 12.01.2011 14:19, Ersue, Mehmet (NSN - DE/Munich) wrote: -Original Message- From: ops-dir-boun...@ietf.org [mailto:ops-dir-boun...@ietf.org] On Behalf Of ext Ersue, Mehmet (NSN - DE/Munich) Sent: Wednesday, January 12, 2011 1:07 PM To: ops-...@ietf.org Cc: draft-yevstifeyev-tn3270-uri-auth...@tools.ietf.org Subject: [OPS-DIR] OPS-DIR Review of draft-yevstifeyev-tn3270-uri-12 I reviewed draft-yevstifeyev-tn3270-uri-12 for its operational impacts.. Summary: The document gives a specification of syntax, semantics and use of 'tn3270' URI scheme. Obviously this is an individual submission without any document write-up and supporting AD. Why without? Peter Saint-Andre is sponsoring AD. I would like to read a document write-up with the regular template even if it is written by the author. The main purpose of the document, namely to update the IANA registration of tn3270 URI scheme using the given registration template, should be added to the Introduction section. In general I would suggest to include in the Introduction section the purpose of the action and more importantly why existing IANA registrations are not sufficient and why the publication of this RFC is needed. Agreed. I'll add that as soon as possible. Obviously the GEN-Area reviewer (Tom Petch) has an opposite opinion and does not see this IANA registration in the interest of IETF (see https://www.ietf.org/ibin/c5i?mid=6&rid=49&gid=0&k1=933&k2=55119&tid=12 9 4831574). The reviewer furthermore states, following the rules in RFC4395 the document should provide concrete contact information for the editor instead of an anonymous email address only. That would be corrected so that the author will be IETF and contact - IESG. I don't see any additional operation impact other than above. Other issues: - The used language needs some polishing. - Following are draft nits suggesting correction: == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -> Use new template or: s/2010/2011/ Will be corrected. -- Obsolete informational reference (is this intentional?): RFC 1738 (Obsoleted by RFC 4248, RFC 4266) -> Use correct reference or clarify. Obsolete Informational references are allowed. I don't see a problem here. Mykyta Mehmet ___ OPS-DIR mailing list ops-...@ietf.org https://www.ietf.org/mailman/listinfo/ops-dir ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call on draft-ietf-pim-registry-03.txt
13.01.2011 13:31, Julian Reschke wrote: On 13.01.2011 10:21, Mykyta Yevstifeyev wrote: Hello all, Let me cite RFC 5226, that says: <...> Documents that create a new namespace (or modify the definition of an existing space) and that expect IANA to play a role in maintaining that space (e.g., serving as a repository for registered values) MUST provide clear instructions on details of the namespace. In particular, instructions *MUST* include: <...> 5) Initial assignments and reservations. Clear instructions should be provided to identify any initial assignments or registrations. In addition, any ranges that are to be reserved for "Private Use", "Reserved", *"Unassigned"*, etc. should be *clearly indicated*. <...> ... That sounds like an editorial error to me. "any ranges to be *reserved* for "Unassigned"..." doesn't make any sense at all. They are not reserved. Yes, that is a type of error, but the meaning is that unassigned and reserved values MUST (yes, must, that is in RFC 5226; see citation below) be mentioned. This should probably be raised as erratum. So the document specifying the regsitry MUST mention what are Unassigned. Moreover, IMO, it would be useful to assign one value for Experimentation. No. should != must. See below. There are tons of registries where this is not the case; namely all or most of those where the values are strings, not numbers. The strings registries are rather exceptions from the rule I cited above. Mykyta Best regards, Julian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Poster sessions
On Tue, Jan 11, 2011 at 2:32 AM, Yoav Nir wrote: > We can have as high a barrier as necessary to ensure there are no more > than, say, 12 posters. That means someone has to judge them and that takes time. > On Jan 11, 2011, at 3:39 AM, John C Klensin wrote: > > > +1. Very strongly. > > > > Whether the logistics of space and times could be worked out or > > not, poster sessions strike me as a really bad idea and Fred has > > summarized at least most of the reasons. If we had a high > > barrier to posting I-Ds, it might be different. But we don't. > > > > john > +1 The problem that this is attempting to get round is the low barrier to publication of IDs which means that there are many of them and ideas get lost. That is not a problem that can be solved by introducing another low barrier to publication venue. -- Website: http://hallambaker.com/ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call on draft-ietf-pim-registry-03.txt
On 13.01.2011 10:21, Mykyta Yevstifeyev wrote: Hello all, Let me cite RFC 5226, that says: <...> Documents that create a new namespace (or modify the definition of an existing space) and that expect IANA to play a role in maintaining that space (e.g., serving as a repository for registered values) MUST provide clear instructions on details of the namespace. In particular, instructions *MUST* include: <...> 5) Initial assignments and reservations. Clear instructions should be provided to identify any initial assignments or registrations. In addition, any ranges that are to be reserved for "Private Use", "Reserved", *"Unassigned"*, etc. should be *clearly indicated*. <...> ... That sounds like an editorial error to me. "any ranges to be *reserved* for "Unassigned"..." doesn't make any sense at all. They are not reserved. This should probably be raised as erratum. So the document specifying the regsitry MUST mention what are Unassigned. Moreover, IMO, it would be useful to assign one value for Experimentation. No. should != must. There are tons of registries where this is not the case; namely all or most of those where the values are strings, not numbers. Best regards, Julian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call on draft-ietf-pim-registry-03.txt
Hello all, Let me cite RFC 5226, that says: <...> Documents that create a new namespace (or modify the definition of an existing space) and that expect IANA to play a role in maintaining that space (e.g., serving as a repository for registered values) MUST provide clear instructions on details of the namespace. In particular, instructions *MUST* include: <...> 5) Initial assignments and reservations. Clear instructions should be provided to identify any initial assignments or registrations. In addition, any ranges that are to be reserved for "Private Use", "Reserved", *"Unassigned"*, etc. should be *clearly indicated*. <...> So the document specifying the regsitry MUST mention what are Unassigned. Moreover, IMO, it would be useful to assign one value for Experimentation. Mykyta 2011/1/13, Julian Reschke : > On 13.01.2011 03:56, Doug Ewell wrote: >> Donald Eastlake wrote: >> >>> Almost all registries I'm familiar with explicitly list unassigned >>> ranges. >> >> The IANA Language Subtag Registry doesn't: >> >> http://www.iana.org/assignments/language-subtag-registry > > Obviously it depends on the datatype whether saying what's unassigned is > useful or feasible. > > Back to ma point: for registries where it *can* be done, the unassigned > values can be *computed*. Thus, they shouldn't be part of the registry > data, but simply be displayed as such. That would ensure that the > information always is up-to-date. > > Best regards, Julian > ___ > 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: Last Call on draft-ietf-pim-registry-03.txt
On 13.01.2011 03:56, Doug Ewell wrote: Donald Eastlake wrote: Almost all registries I'm familiar with explicitly list unassigned ranges. The IANA Language Subtag Registry doesn't: http://www.iana.org/assignments/language-subtag-registry Obviously it depends on the datatype whether saying what's unassigned is useful or feasible. Back to ma point: for registries where it *can* be done, the unassigned values can be *computed*. Thus, they shouldn't be part of the registry data, but simply be displayed as such. That would ensure that the information always is up-to-date. Best regards, Julian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
