Hey bro how are you I don't know what to now I am totally free so just hanging around nothing to everything is just fine I am watching yaadein movie on some channel I don't even know the name of the channel.. Ha ha...
Sent from my iPad On 14-Jun-2012, at 21:41, [email protected] wrote: > If you have received this digest without all the individual message > attachments you will need to update your digest options in your list > subscription. To do so, go to > > https://www.ietf.org/mailman/listinfo/ietf > > Click the 'Unsubscribe or edit options' button, log in, and set "Get > MIME or Plain Text Digests?" to MIME. You can set this option > globally for all the list digests you receive at this point. > > > > Send Ietf mailing list submissions to > [email protected] > > To subscribe or unsubscribe via the World Wide Web, visit > https://www.ietf.org/mailman/listinfo/ietf > or, via email, send a message with subject or body 'help' to > [email protected] > > You can reach the person managing the list at > [email protected] > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Ietf digest..." > > > Today's Topics: > > 1. Re: Publishing the Tao as a web page (Russ Housley) > 2. Re: Publishing the Tao as a web page (John C Klensin) > 3. Re: Publishing the Tao as a web page (Paul Hoffman) > 4. Re: registries and designated experts (John C Klensin) > 5. Re: registries and designated experts (Bjoern Hoehrmann) > 6. Re: Last Call: <draft-polk-ipr-disclosure-03.txt> (Promoting > Compliance with Intellectual Property Rights (IPR) Disclosure > Rules) to Informational RFC (Peter Saint-Andre) > 7. Re: Last Call: <draft-ietf-idr-rfc4893bis-06.txt> (BGP > Support for Four-octet AS Number Space) to Proposed Standard > (John Leslie) > 8. RE: GenART LC review of draft-ietf-nea-pt-tls-05 (Paul Sangster) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Wed, 13 Jun 2012 16:06:59 -0400 > From: Russ Housley <[email protected]> > To: Paul Hoffman <[email protected]> > Cc: IETF discussion list <[email protected]> > Subject: Re: Publishing the Tao as a web page > Message-ID: <[email protected]> > Content-Type: text/plain; charset=us-ascii > > Paul: > > It implies that the current RFC will become the initial web page content. I > think that is not the case. Rather, the initial content will come from > draft-hoffman-tao4677bis. > > Do you want draft-hoffman-tao4677bis to be published as the final RFC version > in the Tao series? > > Russ > > > On Jun 12, 2012, at 7:01 PM, Paul Hoffman wrote: > >> Based on the earlier comments, I have revised the proposal. See >> draft-hoffman-tao-as-web-page-01, diffs at >> <tools.ietf.org/rfcdiff?url2=draft-hoffman-tao-as-web-page-01>. >> >> --Paul Hoffman > > > > ------------------------------ > > Message: 2 > Date: Wed, 13 Jun 2012 16:17:26 -0400 > From: John C Klensin <[email protected]> > To: Russ Housley <[email protected]>, Paul Hoffman > <[email protected]> > Cc: IETF discussion list <[email protected]> > Subject: Re: Publishing the Tao as a web page > Message-ID: <[email protected]> > Content-Type: text/plain; charset=us-ascii > > > > --On Wednesday, June 13, 2012 16:06 -0400 Russ Housley > <[email protected]> wrote: > >> Paul: >> >> It implies that the current RFC will become the initial web >> page content. I think that is not the case. Rather, the >> initial content will come from draft-hoffman-tao4677bis. >> >> Do you want draft-hoffman-tao4677bis to be published as the >> final RFC version in the Tao series? > > Russ, > > If the community cares about developing and maintaining a clear > history of changes, it might be slightly advantageous to: > > (i) Make the current RFC the initial web page content > > (ii) Immediately replace it with a (possibly further > revised) version of draft-hoffman-tao4677bis. > > (iii) Put the Tao aside until we are ready for another > update. > > I have trouble convincing myself that is worth even the marginal > extra effort it would take, but I can see the advantages if > others disagree. On the other hand, publishing > draft-hoffman-tao4677bis in the RFC series seems to me to have > no value at all. There should be an RFC 4677bis but it should > probably say little more than "Tao is now a web page at .... and > it is not being maintained in the RFC Series". > > best, > john > > > > > > ------------------------------ > > Message: 3 > Date: Wed, 13 Jun 2012 13:44:44 -0700 > From: Paul Hoffman <[email protected]> > To: IETF discussion list <[email protected]> > Subject: Re: Publishing the Tao as a web page > Message-ID: <[email protected]> > Content-Type: text/plain; charset=us-ascii > > On Jun 13, 2012, at 1:06 PM, Russ Housley wrote: > >> Paul: >> >> It implies that the current RFC will become the initial web page content. I >> think that is not the case. Rather, the initial content will come from >> draft-hoffman-tao4677bis. > > Good catch. I'll add explicit text in -02 that says that the initial text > will come from the most recent proposed revision (and I will *not* put in a > draft name). > >> Do you want draft-hoffman-tao4677bis to be published as the final RFC >> version in the Tao series? > > No. That seems silly, given that the web page will be done before the RFC. > > On Jun 13, 2012, at 1:17 PM, John C Klensin wrote: > >> If the community cares about developing and maintaining a clear >> history of changes, it might be slightly advantageous to: >> >> (i) Make the current RFC the initial web page content >> >> (ii) Immediately replace it with a (possibly further >> revised) version of draft-hoffman-tao4677bis. >> >> (iii) Put the Tao aside until we are ready for another >> update. > > Yuck. The slight advantage there is hugely overwhelmed by the process > hassles. Instead, the first web page should have a section talking about > where it came from. > >> I have trouble convincing myself that is worth even the marginal >> extra effort it would take, > > Good. :-) > >> but I can see the advantages if >> others disagree. On the other hand, publishing >> draft-hoffman-tao4677bis in the RFC series seems to me to have >> no value at all. There should be an RFC 4677bis but it should >> probably say little more than "Tao is now a web page at .... and >> it is not being maintained in the RFC Series". > > That's the purpose of this document. > > --Paul Hoffman > > > > ------------------------------ > > Message: 4 > Date: Wed, 13 Jun 2012 17:50:30 -0400 > From: John C Klensin <[email protected]> > To: Thomas Narten <[email protected]>, "Romascanu, Dan (Dan)" > <[email protected]> > Cc: SM <[email protected]>, [email protected] > Subject: Re: registries and designated experts > Message-ID: <[email protected]> > Content-Type: text/plain; charset=us-ascii > > > > --On Wednesday, June 13, 2012 08:48 -0400 Thomas Narten > <[email protected]> wrote: > >>> Maybe an IESG statement on this respect can help here. >> >> Is the existing text in RFC 5226 not sufficient? It contains >> extensive text about the purpose and role of designated >> experts, and was revised substantially the last time around to >> try and find a good middle ground between being overly >> prescriptive and giving experts a "blank check" to do what >> they want. >> >> Nothing in the discussion I've seen so far in this thread >> seems at odds with or beyond what is already in RFC 5226 (but >> I may be biased). > > Thomas, > > FWIW, I think 5226 is ok, but that the community, especially the > community who write "Designated Experts" need to pay a little > more attention to a few phrases there than has sometimes been > the case. For example, 5226 says: > > "Ideally, the designated expert follows specific review > criteria as documented with the protocol that creates or > uses the namespace." > > and > > "Experts are expected to apply applicable documented > review or vetting procedures, or in the absence of > documented criteria, follow generally accepted norms, > e.g., those in Section 3.3." > > My impression is that people have perhaps too often skipped > specifying specific guidelines or criteria in their definitions, > leaving the experts to fall back on good sense and the last half > of Section 3.3. That isn't necessarily bad but can easily lead > to misunderstandings if there is actually controversy about a > proposed registration. So I'd recommend that the community pay > a bit more attention during Last Call to whether enough (or too > much) guidance is specified than has often been the case in the > past where we argue protocol details and do a lot of nit-picking > but mostly ignore IANA Considerations sections. > > That doesn't require changes to 5226. But, if 5226 is every > revised, it might be well to check to see if the emphasis in > what it says about this issue is in line with what we want. > > john > > > > ------------------------------ > > Message: 5 > Date: Thu, 14 Jun 2012 04:12:32 +0200 > From: Bjoern Hoehrmann <[email protected]> > To: Randy Bush <[email protected]> > Cc: IETF discussion list <[email protected]> > Subject: Re: registries and designated experts > Message-ID: > <[email protected]> > Content-Type: text/plain; charset=ISO-8859-1 > > * Randy Bush wrote: >>> It seems to me that if an expert reviewer thinks that something will do >>> notable harm, they should decline to make a decision and defer it to the >>> IETF at large >> >> so they are not an expert, they are a rubber stamp? bs. > > Expert reviewers should use their judgement, but that includes whether > their judgement is the right way to resolve some controversy or doubt. > > I was thinking the above more in terms of something about an application > that had not been considered or forseen when the registry was created, > in which case an expert reviewer might want to say they think making > a decision is outside the confines of their role and expectations and > assumptions that have been made when the registry was set up and they > were appointed as reviewer, and reviewers should be expected to do that > as appropriate, in principle. > -- > Bj?rn H?hrmann ? mailto:[email protected] ? http://bjoern.hoehrmann.de > Am Badedeich 7 ? Telefon: +49(0)160/4415681 ? http://www.bjoernsworld.de > 25899 Dageb?ll ? PGP Pub. KeyID: 0xA4357E78 ? http://www.websitedev.de/ > > > ------------------------------ > > Message: 6 > Date: Wed, 13 Jun 2012 21:13:54 -0600 > From: Peter Saint-Andre <[email protected]> > To: [email protected] > Cc: The IESG <[email protected]> > Subject: Re: Last Call: <draft-polk-ipr-disclosure-03.txt> (Promoting > Compliance with Intellectual Property Rights (IPR) Disclosure Rules) > to Informational RFC > Message-ID: <[email protected]> > Content-Type: text/plain; charset=UTF-8 > > On 4/30/12 10:27 AM, The IESG wrote: >> >> The IESG has received a request from an individual submitter to consider >> the following document: >> - 'Promoting Compliance with Intellectual Property Rights (IPR) >> Disclosure Rules' >> <draft-polk-ipr-disclosure-03.txt> as Informational RFC >> >> The IESG plans to make a decision in the next few weeks, and solicits >> final comments on this action. Please send substantive comments to the >> [email protected] mailing lists by 2012-05-28. > > Tim and I received actionable feedback on this list from Stephan Wenger > and Subramanian Moonesamy during the Last Call [1] [2], and Stephan has > publicly verified that his concerns were addressed [3] (SM contacted me > offlist to the same effect). A full diff is at [4], but in brief the > main changes were as follows: > > 1. Tightened some terminology (e.g., changed "limitations" to "licensing > requirements" and, in several places, "IETF participants" to "IETF > contributors" and "authors" to "authors and listed contributors") and > explicitly defined the terms "formal disclosure" and "informal disclosure". > > 2. Clarified that this document does *not* define best current practices > but instead suggests some strategies that ADs, WG chairs, and WG > secretaries might want to use. > > 3. Mentioned that, if informal disclosure is allowed in a meeting, > chairs ought to capture such statements in the meeting minutes. > > 4. Removed a misleading statement that silence could be interpreted as > as a weak "no". > > 5. Removed any suggestion that non-receipt of IPR disclosures could be > interpreted by ADs or WG chairs as necessarily blocking any advancement > of an I-D. > > 6. Tweaked the sample email messages to improve their readability and > better align with the body of the document. > > Peter > > [1] > https://www.ietf.org/ibin/c5i?mid=6&rid=49&gid=0&k1=933&k2=63103&tid=1339642625 > > [2] > https://www.ietf.org/ibin/c5i?mid=6&rid=49&gid=0&k1=933&k2=63414&tid=1339642383 > > [3] > https://www.ietf.org/ibin/c5i?mid=6&rid=49&gid=0&k1=933&k2=63596&tid=1339642383 > > [4] http://tools.ietf.org/rfcdiff?url2=draft-polk-ipr-disclosure-04.txt > > > ------------------------------ > > Message: 7 > Date: Thu, 14 Jun 2012 02:26:10 -0400 > From: John Leslie <[email protected]> > To: Claudio Jeker <[email protected]>, [email protected], > [email protected] > Subject: Re: Last Call: <draft-ietf-idr-rfc4893bis-06.txt> (BGP > Support for Four-octet AS Number Space) to Proposed Standard > Message-ID: <20120614062610.GR21341@verdi> > Content-Type: text/plain; charset=us-ascii > > Enke Chen <[email protected]> wrote: >> On 6/12/12 7:25 AM, Stewart Bryant wrote: >> From: Claudio Jeker <[email protected]> >>> On Tue, Jun 12, 2012 at 11:30:11AM +0100, Stewart Bryant wrote: >>>> On 01/06/2012 23:00, Claudio Jeker wrote: >>>>> On Fri, Jun 01, 2012 at 11:54:44AM -0700, The IESG wrote: >>>>>> >>>>>> The IESG has received a request from the Inter-Domain Routing WG >>>>>> (idr) to consider the following document: >>>>>> - 'BGP Support for Four-octet AS Number Space' >>>>>> <draft-ietf-idr-rfc4893bis-06.txt> as Proposed Standard >>>>>> >>>>>> Abstract >>>>>> >>>>>> The Autonomous System (AS) number is encoded as a two-octet >>>>>> entity in the base BGP specification. This document describes >>>>>> extensions to BGP to carry the Autonomous System numbers as >>>>>> four-octet entities. This document obsoletes RFC 4893. >>>>> >>>>> Just for the sake of clarity, OpenBGPD will not do the following: >>>>> >>>>> In addition, the path segment types AS_CONFED_SEQUENCE and >>>>> AS_CONFED_SET [RFC5065] MUST NOT be carried in the AS4_PATH >>>>> attribute of an UPDATE message. A NEW BGP speaker that receives >>>>> these path segment types in the AS4_PATH attribute of an UPDATE >>>>> message from an OLD BGP speaker MUST discard these path segments, >>>>> adjust the relevant attribute fields accordingly, and continue >>>>> processing the UPDATE message. This case SHOULD be logged locally >>>>> for analysis. >>>>> >>>>> There is no point to do this fiddeling instead we will treat this >>>>> like any other parse error of AS4_PATH. >>>>> >>>>> Claudio > > That would make the OpenBSD implementation non-compliant with 4893bis. > >>>> Since this is in last call, I have to ask whether you have objection >>>> to the publication of the above text, or have any proposed text >>>> changes? >>> >>> I see no reason to enforce AS_CONFED_SEQUENCE and AS_CONFED_SET stripping >>> on all AS4 implementations. It forces bgp implementations that don't have >>> confederation support to strip out something that will cause an error in >>> the regular path and for those systems ignoring the AS4_PATH attribute >>> is perfectly fine. I do not understand how a workaround needs to be a >>> MUST for something that is a MUST NOT at the same time? Why MUST we >>> workaround something that MUST NOT appear? Why do we need to add extra >>> code that is hard to test and maybe cause for further errors because it >>> modifies attributes in very uncommon way? > > Enke explains why this is called for in 4893bis. > > It may help to recall the IETF mantra: "We believe in rough consensus > and running code." > > At the time 4893 was designed, it was a strict requirement in IDR > that nothing could get to Proposed Standard without demonstrating > multiple implementations. In practice, this meant we only documented > something after multiple vendors had it deployed. > > Thus, 4893 went out with bugs (though I was in the rough, explaining > in general terms some weaknesses). > > One bug in particular turned out to be _very_ serious. Patching in > the AS4_PATH produced some AS_CONFED stuff very much out of context. > A fix was desperately needed, and several vendors quickly patched it. > 4893bis, as I understood it, documented this fix. I'm still in the rough, > but I saw no point in objecting to documenting actual practice. > > If in fact, OpenBSD has no intention of patching for this bug, _they_ > need to be considered "in the rough" (as well as non-compliant). > > If, OTOH, they wish to propose a different fix, it's possible the > IESG might ask IDR to consider it. (I can certainly imagine better ways > to resolve the problem.) > > But any fix (IMHO) _must_ dispose of out-of-context AS_CONFED stuff > that still may be in the wild. > >>> I propose to remove that paragraph entierly since it does only add >>> complexity to the protocol for no reason and therefor is only a source >>> of errors without any benefit. > > (I cannot endorse that proposal. It's too likely there's legacy > equipment that allows AS_CONFED stuff to be placed in AS4_PATH.) > >> Hi, Claudio: >> >> Not sure if you are aware of the large scale outage that occurred a few >> years ago from the leak of the confed related segments by one >> implementation. At the time quite a few implementations were resetting >> the sessions when receiving such updates. >> >> While discarding the whole AS4_PATH would be simpler and less disruptive >> (than session resetting), it would still lose the vital as-path info >> contained in the AS4_PATH which can otherwise be recovered by >> "repairing" the attribute. That is why the approach specified in the >> rfc4893bis is adopted, and it has been implemented widely. >> >> -- Enke > > -- > John Leslie <[email protected]> > > > ------------------------------ > > Message: 8 > Date: Wed, 13 Jun 2012 09:55:55 -0700 > From: Paul Sangster <[email protected]> > To: Roni Even <[email protected]>, > "[email protected]" > <[email protected]> > Cc: "[email protected]" <[email protected]>, "[email protected]" > <[email protected]>, 'IETF' <[email protected]> > Subject: RE: GenART LC review of draft-ietf-nea-pt-tls-05 > Message-ID: > > <6e79d623502c70419a9eab18e4d274252b8b061...@tus1xchevspin35.symc.symantec.com> > > Content-Type: text/plain; charset="us-ascii" > > Thanks for the detailed review, comments are in-lined... > > From: Roni Even [mailto:[email protected]] > Sent: Monday, June 04, 2012 2:20 PM > To: [email protected] > Cc: 'IETF'; [email protected] > Subject: GenART LC review of draft-ietf-nea-pt-tls-05 > > I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, > please see the FAQ at > <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>. > > Please resolve these comments along with any other Last Call comments you may > receive. > > > > Document: draft-ietf-nea-pt-tls-05 > > Reviewer: Roni Even > > Review Date:2012-6-4 > > IETF LC End Date: 2012-6-13 > > IESG Telechat date: > > > > Summary: This draft is almost ready for publication as a standard track RFC. > > > > Major issues: > > > > Minor issues: > > 1. In section 3.2 "Therefore, this specification requests the IANA > reserve a TCP port number for use with the PT-TLS protocol upon publication > of this specification as an Internet standard RFC." I think it will be > better to have here the assigned port number and instruct the RFC editor to > put the correct value. > > > > [PS:] Ok, we can reword this in hopes of getting a particular value (race > condition with other upcoming RFCs). > > > > 2. In section 3.4.2.2 last paragraph you summarize the text from > section 3.8 while in the paragraph above you provide the reference. Why do > you need the last paragraph if 3.8 is referenced. > > > > [PS:] The goal of this section is to introduce and summarize the different > phases of PT-TLS. We felt a brief discussion of the general message flow was > helpful to the reader to understand what occurs during this phase (similar to > what we did in the other sub-sections). Your correct that this information > is covered later in more detail. > > > > 3. In various places you refer to SMI 0 as IETF SMI number while > according to the table it is IANA SMI number. > > > > [PS:] I presume this is about the PEN 0 being for the IETF. Correct, it's > the IETF's name space that administered by the IANA. What text would you > like to see to make this more clear? Can we do it in one place, for example > stating that the IETF name space is administered by the IANA? > > > > 4. I assume that all implementations MUST support message type vendor > ID 0. Is this mentioned? > > > > [PS:] The purpose of this section was just to summarize and enumerate the > message types for vendor id 0. I don't think it's a general rule that any > message type defined in the IETF (IANA :)) name space must (or should be) > supported by all implementations. It will vary depending on the purpose of > the message so that normative language is included in the descriptions of the > message. > > > > 5. In section 3.5 and 6.1 you propose a policy of "Expert Review with > Specification Required ". I think that according to RFC5226 expert review is > implied if you select a specification required policy. > > > > [PS:] I agree, it says "Specification Required also implies use of a > Designated Expert". The policy is just "Specification Required" so we could > remove the "Expert Review with" and make it clear it's the Specification > Required IANA policy. > > > > 6. In section 3.6 on 9+ "Recipients of messages of type 9 or higher > that do not support the PT-TLS Message Type Vendor ID and PT-TLS Message Type > of a received PT-TLS message MUST respond with a Type Not Supported PT-TLS > error code in a PT-TLS Error message." I think this is true only for Message > Type Vendor ID 0. > > > > [PS:] Thanks will reword this section to make it more clear. > > > > 7. In 3.7.1 for Max vers and prefs ver you say that they MUST be set to > 1. I think it will be more correct here to say SHOULD since you explain > afterwards that they may have other values. > > > > [PS:] I think this is a MUST. The next sentence just points out that this > normative text might change in a future revision (which is not currently > planned). > > > > 8. In section 3.7.2 "the recipient SHOULD send". Why not make it a MUST > here. > > > > [PS:] I ok with making this change, let's see what others think ... > > > > 9. In section 3.7.2 "The version selected MUST be within the Min Vers > to Max Vers inclusive range sent in the Version Request Message" I was > expecting to see pref ver here. > > > > [PS:] Perf is just an informational (hint) preference. > > > > 10. In section 3.8.3 " The SASL client authentication starts when the NEA > Server enters the PT-TLS Negotiation phase and its policy indicates that an > authentication of the NEA Client is necessary but was not performed during > the TLS handshake protocol " my read of section 3.8 second paragraph is that > it can be done even if was done in the TLS handshake so the last part of the > sentence is not correct, if there is a policy you do it anyhow. This comment > is also for the third paragraph. > > > > [PS:] Thanks, this was supposed to be an example. Will fix these. > > > > 11. In section 3.9 I noticed that you propose to send the entire original > message. Isn't it enough to send only the message identifier. This is based > on the last sentence of this section. > > > > [PS:] Not "the entire original message" as its at most the first 1024 bytes > of the offending message. This allows the recipient to either caches > recently sent messages and/or message identifiers when determining what > caused the error. We thought this flexibility was useful and had very little > cost. > > > > 12. Most of the text in section 6.1 repeats RFC5226 but in your words. Are > you trying to change some of RFC5226 text if not why write it in different > words? > > > > [PS:] We were hoping to emphasize the aspects of 5226 that are most important > to this specification. We weren't trying to change how the IANA policy was > interpreted. Did you think we did so? Is there a portion of this text that > is most troubling or was this just a question? > > > > > > > > > > Nits/editorial comments: > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > <http://www.ietf.org/mail-archive/web/ietf/attachments/20120613/c733cf1b/attachment.htm> > > ------------------------------ > > _______________________________________________ > Ietf mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/ietf > > > End of Ietf Digest, Vol 49, Issue 40 > ************************************
