Re: Ietf Digest, Vol 49, Issue 40

[[e-mail]]

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, [e-mail] 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
>    [e-mail]
> 
> 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
>    [e-mail]
> 
> You can reach the person managing the list at
>    [e-mail]
> 
> 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 <[e-mail]>
> To: Paul Hoffman <[e-mail]>
> Cc: IETF discussion list <[e-mail]>
> Subject: Re: Publishing the Tao as a web page
> Message-ID: <[e-mail]>
> 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 <[e-mail]>
> To: Russ Housley <[e-mail]>, Paul Hoffman
>    <[e-mail]>
> Cc: IETF discussion list <[e-mail]>
> Subject: Re: Publishing the Tao as a web page
> Message-ID: <[e-mail]>
> Content-Type: text/plain; charset=us-ascii
> 
> 
> 
> --On Wednesday, June 13, 2012 16:06 -0400 Russ Housley
> <[e-mail]> 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 <[e-mail]>
> To: IETF discussion list <[e-mail]>
> Subject: Re: Publishing the Tao as a web page
> Message-ID: <[e-mail]>
> 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 <[e-mail]>
> To: Thomas Narten <[e-mail]>,    "Romascanu, Dan (Dan)"
>    <[e-mail]>
> Cc: SM <[e-mail]>, [e-mail]
> Subject: Re: registries and designated experts
> Message-ID: <[e-mail]>
> Content-Type: text/plain; charset=us-ascii
> 
> 
> 
> --On Wednesday, June 13, 2012 08:48 -0400 Thomas Narten
> <[e-mail]> 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 <[e-mail]>
> To: Randy Bush <[e-mail]>
> Cc: IETF discussion list <[e-mail]>
> Subject: Re: registries and designated experts
> Message-ID:
>    <[e-mail]>
> 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:[e-mail] ? http://bjoern.hoehrmann.de
> Am Badedeich 7 ? Telefon: [phone] ? 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 <[e-mail]>
> To: [e-mail]
> Cc: The IESG <[e-mail]>
> Subject: Re: Last Call: <draft-polk-ipr-disclosure-03.txt> (Promoting
>    Compliance    with Intellectual Property Rights (IPR) Disclosure Rules)
>    to    Informational RFC
> Message-ID: <[e-mail]>
> 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
>> [e-mail] 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 <[e-mail]>
> To: Claudio Jeker <[e-mail]>, [e-mail],
>    [e-mail]
> 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 <[e-mail]> wrote:
>> On 6/12/12 7:25 AM, Stewart Bryant wrote:
>> From:     Claudio Jeker <[e-mail]>
>>> 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 <[e-mail]>
> 
> 
> ------------------------------
> 
> Message: 8
> Date: Wed, 13 Jun 2012 09:55:55 -0700
> From: Paul Sangster <[e-mail]>
> To: Roni Even <[e-mail]>,
>    "[e-mail]"
>    <[e-mail]>
> Cc: "[e-mail]" <[e-mail]>, "[e-mail]"
>    <[e-mail]>,    'IETF' <[e-mail]>
> Subject: RE: GenART LC review of draft-ietf-nea-pt-tls-05
> Message-ID:
>    <[e-mail]>
>    
> Content-Type: text/plain; charset="us-ascii"
> 
> Thanks for the detailed review, comments are in-lined...
> 
> From: Roni Even [mailto:[e-mail]]
> Sent: Monday, June 04, 2012 2:20 PM
> To: [e-mail]
> Cc: 'IETF'; [e-mail]
> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ietf
> 
> 
> End of Ietf Digest, Vol 49, Issue 40
> ************************************