ietf
[Top] [All Lists]

Re: Ietf Digest, Vol 49, Issue 40

2012-06-14 12:23:45
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, ietf-request(_at_)ietf(_dot_)org 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
   ietf(_at_)ietf(_dot_)org

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
   ietf-request(_at_)ietf(_dot_)org

You can reach the person managing the list at
   ietf-owner(_at_)ietf(_dot_)org

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 <housley(_at_)vigilsec(_dot_)com>
To: Paul Hoffman <paul(_dot_)hoffman(_at_)vpnc(_dot_)org>
Cc: IETF discussion list <ietf(_at_)ietf(_dot_)org>
Subject: Re: Publishing the Tao as a web page
Message-ID: <B0C00137-E868-4017-AF5D-932848AEF6A2(_at_)vigilsec(_dot_)com>
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 <john-ietf(_at_)jck(_dot_)com>
To: Russ Housley <housley(_at_)vigilsec(_dot_)com>, Paul Hoffman
   <paul(_dot_)hoffman(_at_)vpnc(_dot_)org>
Cc: IETF discussion list <ietf(_at_)ietf(_dot_)org>
Subject: Re: Publishing the Tao as a web page
Message-ID: <55DD186626302C4F0AB644C4(_at_)JcK-HP8200(_dot_)jck(_dot_)com>
Content-Type: text/plain; charset=us-ascii



--On Wednesday, June 13, 2012 16:06 -0400 Russ Housley
<housley(_at_)vigilsec(_dot_)com> 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 <paul(_dot_)hoffman(_at_)vpnc(_dot_)org>
To: IETF discussion list <ietf(_at_)ietf(_dot_)org>
Subject: Re: Publishing the Tao as a web page
Message-ID: <6D41FAFE-6B15-4CD5-AB00-59DE8E93AC7B(_at_)vpnc(_dot_)org>
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 <john-ietf(_at_)jck(_dot_)com>
To: Thomas Narten <narten(_at_)us(_dot_)ibm(_dot_)com>,    "Romascanu, Dan 
(Dan)"
   <dromasca(_at_)avaya(_dot_)com>
Cc: SM <sm(_at_)resistor(_dot_)net>, ietf(_at_)ietf(_dot_)org
Subject: Re: registries and designated experts
Message-ID: <21E957EA9B7C80B51E88AE22(_at_)JcK-HP8200(_dot_)jck(_dot_)com>
Content-Type: text/plain; charset=us-ascii



--On Wednesday, June 13, 2012 08:48 -0400 Thomas Narten
<narten(_at_)us(_dot_)ibm(_dot_)com> 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 <derhoermi(_at_)gmx(_dot_)net>
To: Randy Bush <randy(_at_)psg(_dot_)com>
Cc: IETF discussion list <ietf(_at_)ietf(_dot_)org>
Subject: Re: registries and designated experts
Message-ID:
   
<l8bit7h15gu6go57e5o82jgkf22mj5ki69(_at_)hive(_dot_)bjoern(_dot_)hoehrmann(_dot_)de>
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:bjoern(_at_)hoehrmann(_dot_)de ? 
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 <stpeter(_at_)stpeter(_dot_)im>
To: ietf(_at_)ietf(_dot_)org
Cc: The IESG <iesg(_at_)ietf(_dot_)org>
Subject: Re: Last Call: <draft-polk-ipr-disclosure-03.txt> (Promoting
   Compliance    with Intellectual Property Rights (IPR) Disclosure Rules)
   to    Informational RFC
Message-ID: <4FD956F2(_dot_)6070609(_at_)stpeter(_dot_)im>
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
ietf(_at_)ietf(_dot_)org 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 <john(_at_)jlc(_dot_)net>
To: Claudio Jeker <cjeker(_at_)diehard(_dot_)n-r-g(_dot_)com>, 
idr(_at_)ietf(_dot_)org,
   ietf(_at_)ietf(_dot_)org
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 <enkechen(_at_)cisco(_dot_)com> wrote:
On 6/12/12 7:25 AM, Stewart Bryant wrote:
From:     Claudio Jeker <cjeker(_at_)diehard(_dot_)n-r-g(_dot_)com>
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 <john(_at_)jlc(_dot_)net>


------------------------------

Message: 8
Date: Wed, 13 Jun 2012 09:55:55 -0700
From: Paul Sangster <Paul_Sangster(_at_)symantec(_dot_)com>
To: Roni Even <ron(_dot_)even(_dot_)tlv(_at_)gmail(_dot_)com>,
   "draft-ietf-nea-pt-tls(_dot_)all(_at_)tools(_dot_)ietf(_dot_)org"
   <draft-ietf-nea-pt-tls(_dot_)all(_at_)tools(_dot_)ietf(_dot_)org>
Cc: "gen-art(_at_)ietf(_dot_)org" <gen-art(_at_)ietf(_dot_)org>, 
"nea(_at_)ietf(_dot_)org"
   <nea(_at_)ietf(_dot_)org>,    'IETF' <ietf(_at_)ietf(_dot_)org>
Subject: RE: GenART LC review of draft-ietf-nea-pt-tls-05
Message-ID:
   
<6E79D623502C70419A9EAB18E4D274252B8B06102F(_at_)TUS1XCHEVSPIN35(_dot_)SYMC(_dot_)SYMANTEC(_dot_)COM>
   
Content-Type: text/plain; charset="us-ascii"

Thanks for the detailed review, comments are in-lined...

From: Roni Even [mailto:ron(_dot_)even(_dot_)tlv(_at_)gmail(_dot_)com]
Sent: Monday, June 04, 2012 2:20 PM
To: draft-ietf-nea-pt-tls(_dot_)all(_at_)tools(_dot_)ietf(_dot_)org
Cc: 'IETF'; gen-art(_at_)ietf(_dot_)org
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
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf


End of Ietf Digest, Vol 49, Issue 40
************************************

<Prev in Thread] Current Thread [Next in Thread>
  • Re: Ietf Digest, Vol 49, Issue 40, anandmadhab <=