Re: Document Action: 'ANSI C12.22, IEEE 1703 and MC12.22 TransportOver IP' to Informational RFC
Is this document misnamed? I see more about how to put IP inside ANSI C12.22 management data structs than how to do C12.22 over IP. Something as important as this should really be in a WG and get a more thorough review. Also, based on previous XXX over IP work performed in the IETF, shouldn't this be standards track? Thanks On 10/27/10 5:04 AM, Ralph Droms wrote: > Avygdor - can you tell me more about the implementations on which the > document is based? > > - Ralph > > > On Oct 27, 2010, at 2:50 AM 10/27/10, Avygdor Moise wrote: > >> Dear Mr. St. Johns, >> >> Respectfully, I think that it is not the purpose of the RFC to state what it >> is not. >> The term "all known" cleanly relates to the authors' knowledge of known >> implementations. Certainly there may be a few implementations that do not >> follow this RFC, but the same is true nearly for any known Standard. >> Also the term "several proprietary C12.22 over IP implementations" is rather >> strong in view of the history of the C12 Standards and the manner in which >> they are implemented. >> >> Avygdor Moise >> >> - Original Message - From: "Michael StJohns" >> To: "Ralph Droms" ; "Avygdor Moise" >> Cc: "Ralph Droms" ; "Jonathan Brodkin" >> ; "IETF Discussion" ; "IESG IESG" >> >> Sent: Tuesday, October 26, 2010 4:24 PM >> Subject: Re: Document Action: 'ANSI C12.22, IEEE 1703 and MC12.22 >> TransportOver IP' to Informational RFC >> >> >>> Hi Ralph - >>> >>> Exactly what I was getting at. But a slight change in the wording you >>> suggested to make things clear. >>> >>> Instead as the first paragraph of the abstract or as an RFC editor note I >>> suggest: >>> >>> "This document is not an official submission on behalf of the ANSI C12.19 >>> and C12.22 working groups. It was created by participants in those groups >>> building on knowledge of several proprietary C12.22 over IP >>> implementations. The content of this document is an expression of a >>> consensus aggregation of those implementations." >>> >>> >>> This, unlike your formulation, doesn't beg the question of whether or not >>> "existing implementations" and "all known" means "every single one >>> including ones not publicly announced" >>> >>> Thanks, Mike >>> >>> >>> At 05:34 PM 10/26/2010, Ralph Droms wrote: Combining an excellent suggestion from Donald and Avygdor's clarification as to the official status of this document, I suggest an RFC Editor note to add the following text as a new last paragraph in the Introduction: This document was created by technical experts of the ANSI C12.22 and ANSI C12.19 Standards, based on they first hand implementation knowledge of existing C12.22 implementations for the Internet. It is not an official and approved submission on behalf of the ANSI C12.22 and ANSI C12.19 working groups. The content of this document is an expression on the aggregate experience of all known implementations of ANSI C12.22 for the SmartGrid using the Internet. - Ralph On Oct 26, 2010, at 5:25 PM 10/26/10, Avygdor Moise wrote: > Mr. St. Johns, > > You ask: "Is this document an official and approved submission on behalf > of the ANSI C12.22 and ANSI C12.19 working groups?" > Answer: No it is not. > > The ANSI C12.22 and ANSI C12.19 standards do not define the Transport > Layer interfaces to the network. They only define the Application Layer > Services and content. > This RFC addressed the gap as it applies to transporting C12.22 APDUs > over the Internet. However technical experts that were involved in the > making, deploying, testing and documenting the referred standards > contributed to the making of this RFC. > > ANSI, NEMA, NIST, SGIP, MC, IEEE, IETF, AEIC and EEI are fully aware of > this effort and this RFC. The work was carried in plain view. > > Avygdor Moise > - Original Message - > From: Michael StJohns > To: Avygdor Moise > Cc: ietf@ietf.org ; IESG IESG ; Jonathan Brodkin > Sent: Tuesday, October 26, 2010 2:58 PM > Subject: RE: Document Action: 'ANSI C12.22, IEEE 1703 and MC12.22 > TransportOver IP' to Informational RFC > > One simple question: Is this document an official and approved > submission on behalf of the ANSI C12.22 and ANSI C12.19 working groups? > > > The specific language in the IESG record (in the working group summary) is > > > "This document was created by technical experts of the ANSI > C12.22 > and ANSI C12.19 Standards, based on they first hand > implementation > knowledge of existing C12.22 implementations for the Internet. > Its > content is an expression on the aggregate experience of all known > implementations of ANSI C12.22 for the SmartGrid using the > internet." > > > > "Created by Technical Experts of the ..." is NOT
RE: SOAP/XML Protocol and filtering, etc.
Why would a firewall or a firewall admin trust the packet to indicate what it really is? Bora At 2:50 PM -0700 5/7/01, Henrik Frystyk Nielsen wrote: >The meaning of SOAPAction is not to say that "this is a stockquote >service" but to say that "I am sending you a SOAP message of a type that >is part of a stock quote service". > >The difference is that one is a destination which is carried in HTTP by >the request-URI but the other is a hint about what is in the message. >This is why SOAPAction is a separate parameter. > >Henrik > >>> On Sun, May 06, 2001 at 03:12:08PM -0400, Keith Moore wrote: >>> > and client APIs. It also keeps HTTP servers from having to know >>> > specifically whether a particular URI corresponds with a SOAP >>> > request (in which case it might have to look at the SOAPAction >>> > header in order to know how to handle it) or not (in which case the > >>> > SOAPAction header should be ignored). >>> >>> Yep; seems to me that Content-Type ss more appropriate for dispatch, >>> if doing it in a header is desireable. > > > >ugh. only if you must. the URL is *far* better for this purpose.
Re: bandwidth (and other support) required for multicast
That doesn't help those of us that are behind firewalls ;-) I like the way NANOG handles the broadcasts. Maybe we can get one of the content distributors like Akamai to host the Quicktime broadcast. Bora Writing this from a powerbook running MasOS X On Friday, March 30, 2001, at 09:20 AM, Joel Jaeggli wrote: > On Thu, 29 Mar 2001, Lyndon Nerenberg wrote: > >>> Oh, and of course Internet standards based players are available for >>> all platforms, right? >> >> Yes (for a larger value of "all" than RealPlayer supports). vic/vat/rat >> are portable to many UNIX variants, and also run under Windows. I >> think that MacOS is the only orphan in this scenario, but ISTR there > > macos has quicktime 5.0 which can handle both the h.261/pcm and mpeg > stream > >> are protocol proxies available that will gateway to something MacOS >> can handle (assuming they can't directly view H.261 multicast with >> some other tools). >> >> --lyndon >> > > -- > -- > Joel Jaeggli [EMAIL PROTECTED] > Academic User Services [EMAIL PROTECTED] > PGP Key Fingerprint: 1DE9 8FCA 51FB 4195 B42A 9C32 A30D 121E > -- > It is clear that the arm of criticism cannot replace the criticism of > arms. Karl Marx -- Introduction to the critique of Hegel's Philosophy > of > the right, 1843. >
Re: RFCs in PDF
The only way I have found on Win 2K to print RFCs while preserving formatting is to ps-print them from emacs running on Windows. You can even print to a networked printer. Bora On Wed, 28 Mar 2001, Keith Moore wrote: > At one time I was told by several folks that Windows users have a difficult > time dealing with RFCs because there is no program that ships with Windows > that can print RFCs while preserving page breaks. (of course, some people > might be content to view RFCs on a screen, but the people who were complaining > were in fact printer developers - who presumably prefer hardcopy :) > > This was a few years ago, so perhaps this situation has changed somewhat. > But just on a whim I decided to produce a set of RFCs in PDF and solicit > feedback about how useful they are. > > http://www.cs.utk.edu/~moore/RFC-PDF/index.html > > Keith > > p.s. Don't expect these to be any more beautiful than their originals - > the goal has been to reproduce them faithfully, not to pretty them up. >
Re: What is the differents between Switch and Router?
Maybe he meant directed broadcast as in 10.10.255.255 ? Bora On Sat, 17 Mar 2001, Randy Bush wrote: > >> A router decrements the IP TTL field. > > It should also not propagate broadcast IP packets (subnet or all 1's). > > for a non-attached subnet, what is a broadcast packet? >
Re: What is the differents between Switch and Router?
Layer 3 switch = Router (IMHO) esp in today's world. All layer 3 switches that are routing packets using layer 3 addresses must follow RFC1812 etc. Layer 2 switch != Router. They commonly do Ethernet stuff. Bora On Fri, 16 Mar 2001, Joe Touch wrote: > > > Harald Alvestrand wrote: > > > > At 09:03 15/03/2001 +0800, huangjianbo wrote: > > >I am working on a paper on router, but one problem blocked my process. That > > >is what's the differents between a switch and a router for the view of > > >theoritical. > > > > > >As to the 3 Layer switch and router, both of them work as a distributor > > >based on the IP address. Just some small differents usage and implemention. > > > > > > > > >Of coourse, we disscuss this problem on the switch and router on the same > > >layer. > > > > A router decrements the IP TTL field. > > It should also not propagate broadcast IP packets (subnet or all 1's). > (Any other hard requirements?) > > Joe >
Re: rfc publication suggestions
At 12:07 PM -0500 3/15/01, Melinda Shore wrote: > > If you are a technical person and so a past, present, or potential >> RFC author, you will have your own systems and chances better than >> even that at least some of them will have `man` and `nroff`. > >A draft formatted with Word recently crossed my >path, and the formatting was *so* bad that the >document wasn't readable (for some reason something >in the Word -> text process deleted all vertical >whitespace). I reformatted it with nroff under >UWIN, which really worked very well and held no >surprises whatsoever. So, it's not even necessary >to have access to a Unix or Unix-ish OS to use >nroff for document production. > >Melinda This one is because of a bad printer driver in Windows until 2K. Win2K generic text printer does not have this problem. Don't ask me how I know. Bora
Re: HTML better for small PDAs
I guess I have to hold up this "letter" sized paper display and try to write on it at the same time. I'll believe it when I see it. I saw the article on this topic in MIT Tech review a few months ago, but they were saying that this technology is years ahead. In the meantime, I will keep on using my Pilot (oops Palm). Bora On Mon, 26 Feb 2001, Lyndon Nerenberg wrote: > > the hardware problem is the eyes and the hands. i use a pda because i can > > put it in my hip pocket. that's just not going to happen with a screen that > > half-size or full-size. > > You're thinking too traditionally. Displays will decouple from the > processor (think Bluetooth). The "CPU" will holster on your belt, > and the A4 sized thin-film display will fold up to fit in your pocket. > And pixel density will increase to approach that of paper. (At 300 DPI > you can shrink the font enough to get the better part of a 60x72 character > page onto even todays sized PDA displays if you display in landscape.) > > Or maybe the technology will be something else. The point is that > the display technology _will_ be there, and it will be there soon. > (Soon enough that current PDA limitations aren't a good enough > justification - IMO - for the sort of changes we're talking about > making.) > > --lyndon >
Re: HTML better for small PDAs
At 3:57 PM -0700 2/26/01, Lyndon Nerenberg wrote: > > what i do care about is the fact that ASCII memos can't be >reformatted. that >> is just plain silly. > >Marshall, do you think tiny PDA displays will be with us for a >substantial amount of time? It seems to me that, with the rate >display technology moves forward at, by the time we all finish >arguing over this the current crop of postage-stamp size PDA >displays will be ancient history. > >There's more to this than just ID's/RFCs. Pretty damned near >everything has to be reformatted to fit on those itty-bitty screens, >and that just isn't going to happen. Consumers will demand (and >get) readable displays. I really think we're better of fixing this >problem in hardware. > >--lyndon Are your pockets getting any bigger, I don't see anyone carrying a laptop holster on their belts? The reason that PDA screens are small are because PDAs are small. Apple Newton (which I still own) had a larger screen but it wasn't as convenient as a Palm to carry around. I have read reasonable size text docs on both and it is really not that bad. Bora
Re: HTML better for small PDAs
I would very much like to see support for XML+ASCII in IETF. Bora At 2:33 PM -0800 2/26/01, Marshall T. Rose wrote: >vern - i hope we can agree that i don't fall under the categorization of > >> those who have not yet found an opportunity to Contribute To The Standards >> Process > >if we disagree on this, then discard this message. > >i will tell you why i think it is a good idea that the I-D repository accept >XML versions of drafts, whilst retaining the .txt versions as the "official" >ones (assuming that the term "official internet-draft" isn't oxymoronic). > >the text format we use for I-Ds and RFCs is final form. it works great for >printing. it works pretty well for viewing on a nice screen. it doesn't work >well on a small screen. > >the advantage of using something like XML is that it is an intermediate >form. this means that i can write programs that convert it to different >final forms, e.g., something that looks nice on a pda. today i flew from >sacramento to boston, rather than carrying around 500 pages of recent I-Ds, >i loaded them onto my ipaq. although i avoided a trip to the chiropractor >for my back, i now have to see him for the rsi i got from having to scroll >left-right in addition to up-down. > >i don't know if html is better for small PDAs, and frankly, i don't care. >what i do care about is the fact that ASCII memos can't be reformatted. that >is just plain silly. > >so, i suggest a simple experiment: let the I-D repository store alternative >versions of drafts in addition to the .txt versions. try this out for 9 >months and see if people find it useful or not. is this really asking so >much? > >/mtr
Re: HTML better for small PDAs
Vernon, You obviously enjoy drawing ASCII art, some of us don't. Bora
Writing Internet Drafts on a Macintosh
I am trying (trying is the key word) to write Internet drafts on a powerbook using MS Word with the template from the IETF web-site, then using a PC to convert Word to text per the instructions. Is there a better way to write IDs on a Mac? Also, why isn't HTML an accepted format for Internet Drafts, pretty much everyone on the planet should be able to read an HTML file (even using Lynx on a terminal)? Regards, Bora Akyol
Re: How many routers an OSPF or IS-IS area can have
I think the max numbers are somewhat conservative. There are SPs that run more than 350 routers in one area successfully these days. Bora > "Jerome" == Jerome Etienne <[EMAIL PROTECTED]> writes: Jerome> rfc2329 may help you. Parameter Responses Min Mode Jerome> Mean Max Jerome> _ Jerome> Max routers in domain 8 20 350 510 1000 Max routers Jerome> in single area 8 20 100 160 350 Max areas in domain Jerome> 7 1 15 23 60 Max AS-external-LSAs 6 50 1K 2K 5K Jerome> Table 3: OSPF domain sizes Jerome> deployed Jerome> On Thu, Jan 25, 2001 at 08:35:15AM -0600, David Wang Jerome> wrote: >> Hi, >> >> I have a question about the size of the IS-IS and OSPF >> area. What is the guidelines in setting up the IS-IS or >> OSPF area? How many routers an area can have? What are >> the key facts to determine how many routers an area can >> have? router memory size? router interface bandwidth? or >> some other facts? Is there any quantitative relationship >> among various parameters? >> >> Thank you for your help! >> >> David
RE: Antigen found W32/Navidad.e@M (McAfee4) virus
What is really funny is that the IETF mailing list is doing this. Bora > "Lillian" == Lillian Komlossy <[EMAIL PROTECTED]> writes: Lillian> Aaaarrrggg Lillian Komlossy || Site Lillian> Manager || http://www.dmnews.com || Lillian> http://www.imarketingnews.com || 212 925-7300 Lillian> ext. 232 || mailto:[EMAIL PROTECTED] Lillian> -Original Message- From: [EMAIL PROTECTED] Lillian> [mailto:[EMAIL PROTECTED]] Sent: Thursday, January Lillian> 18, 2001 12:47 PM To: [EMAIL PROTECTED]; Lillian> [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; Lillian> [EMAIL PROTECTED] Subject: Antigen found Lillian> W32/Navidad.e@M (McAfee4) virus Lillian> Antigen for Exchange found Emanuel.exe infected Lillian> with W32/Navidad.e@M (McAfee4) virus. The file is Lillian> currently Deleted. The message, "Re: Call For Lillian> Paper : IEEE Symposium on Ad Hoc Wireless Networks Lillian> (SAWN) 2001", was sent from Wu Jun and was Lillian> discovered in Illan Glasner\Deleted Items located Lillian> at Unknown/Unknown/MSMAIL.
