Re: Comments on draft-ietf-bfd-unaffiliated-echo-08

Greg Mirsky <gregimirsky@gmail.com> Thu, 28 September 2023 16:03 UTC

Return-Path: <gregimirsky@gmail.com>
X-Original-To: rtg-bfd@ietfa.amsl.com
Delivered-To: rtg-bfd@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AEDC1C14F748; Thu, 28 Sep 2023 09:03:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.105
X-Spam-Level:
X-Spam-Status: No, score=-7.105 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I42FHUhtVegf; Thu, 28 Sep 2023 09:03:42 -0700 (PDT)
Received: from mail-yb1-xb35.google.com (mail-yb1-xb35.google.com [IPv6:2607:f8b0:4864:20::b35]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9753EC14F721; Thu, 28 Sep 2023 09:03:42 -0700 (PDT)
Received: by mail-yb1-xb35.google.com with SMTP id 3f1490d57ef6-d867d4cf835so11114085276.1; Thu, 28 Sep 2023 09:03:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1695917021; x=1696521821; darn=ietf.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=vGLawiA2rxQ0HN1Ozg446uu6CCQcIcg1RkHU7zwAs5c=; b=BqxNMBzEt+vcq1hlAquif0800QuePDB+wr5HRuccaI25jOjEfElbr0SLCMvTYeG4YO 54xwWW+5Ph5bw+X3sPMGBvPdPW5YOwBFzwH5+5UeyjZUdymV4b2FYegNO7BlqdDItFFx BXtvMxY7pxUpOQ1A9Q6WbSouQ5ex+l9cXn6csa+o6oQHpTEAngxh0wZ9P5G6PL13ongm 2kfVnYrGdbh2F9LB9gIUgQrzym15nHLSwnMf+EvsTc4O8ByxxLyGi6N+uescZ0XucVc6 E//uUd1yVutKepvNY5hqMHyM7KvUTzSUu4tAKCRw8exBVU6S278lmXEe7IcsbfIrQGjK /WYw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1695917021; x=1696521821; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=vGLawiA2rxQ0HN1Ozg446uu6CCQcIcg1RkHU7zwAs5c=; b=Gf8HeBez5anrR04rcfZWjd/hT3P2+1mxA+FF7/bmcBmw/L7U8jm5UEGECu44CiF0F4 poHhNOxRFnoo5mhioeWrpTDay0VjpRVJbDlofU711k3+wdcGMIZ9ybrycdVPxmjMg2eJ uCc1dwdGmkDtEYpJWjSeNpDd8jKzudCEG1ZECQuQOrrKGwq5k/KbQWHyic7MyXAc7bo7 wl0T8JLeomcnxxRnLeXTeIVBcEDQXWHWhpwm4ekno4/KvXKd9N7y2EPExMERbiKnj9K5 KsLi2bhm/0VFfdEWQoRLz113r8uZuogpgBD30NbMRp0penuDxhnxYfPBNptlCt+qpnxB sHaw==
X-Gm-Message-State: AOJu0YwrVR+IInJUHAm40tcIzlpwXo14pKOR6WZOvA3cS2a9JU72M5o/ COy73pqSbxZOTFvERQNX5Y1glBgPcMGWr56+zs8=
X-Google-Smtp-Source: AGHT+IGmrhyN8tff9W1kleVOGswL3ju/blx7yj33idchBsNYK1URmN/HzSfiXOBMattRC3kCRzqD8hdJ1193CN9lCDM=
X-Received: by 2002:a25:6f08:0:b0:d78:1ec6:6a02 with SMTP id k8-20020a256f08000000b00d781ec66a02mr1725534ybc.8.1695917020841; Thu, 28 Sep 2023 09:03:40 -0700 (PDT)
MIME-Version: 1.0
References: <CA+RyBmVCZoUeQ0S2kqYw1zy3pSrqhx7gWaFUoAnjFiPpKQ-yEg@mail.gmail.com> <202309270937414157322@zte.com.cn> <CA+RyBmXSBzXn_s=8oCO3g1Z0FFFs+Z=LQ9KU1s4ib+bLjJWoAA@mail.gmail.com> <CAH6gdPzO01SF=zpr4QynymRyXSv_Mh1C=d0wOpj_CeiOAVfZKA@mail.gmail.com>
In-Reply-To: <CAH6gdPzO01SF=zpr4QynymRyXSv_Mh1C=d0wOpj_CeiOAVfZKA@mail.gmail.com>
From: Greg Mirsky <gregimirsky@gmail.com>
Date: Thu, 28 Sep 2023 09:03:29 -0700
Message-ID: <CA+RyBmXiVQLSw4+dk3CS2sE6XxEih8c9L2tjpqNoBcN11k__3A@mail.gmail.com>
Subject: Re: Comments on draft-ietf-bfd-unaffiliated-echo-08
To: Ketan Talaulikar <ketant.ietf@gmail.com>
Cc: xiao.min2@zte.com.cn, rtg-bfd@ietf.org, draft-ietf-bfd-unaffiliated-echo@ietf.org
Content-Type: multipart/alternative; boundary="000000000000988d1406066d7385"
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-bfd/pziaHucvlBHk4C6pu-dDM04nSNs>
X-BeenThere: rtg-bfd@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "RTG Area: Bidirectional Forwarding Detection DT" <rtg-bfd.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtg-bfd>, <mailto:rtg-bfd-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rtg-bfd/>
List-Post: <mailto:rtg-bfd@ietf.org>
List-Help: <mailto:rtg-bfd-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtg-bfd>, <mailto:rtg-bfd-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 28 Sep 2023 16:03:46 -0000

Hi Xiao Min and Ketan,
thank you for your thoughtful consideration of my note; much appreciated.
Both proposed updates are acceptable to me. If the Authors accept the text
suggested by Ketan, then we can close this issue.

Regards,
Greg

On Thu, Sep 28, 2023 at 12:17 AM Ketan Talaulikar <ketant.ietf@gmail.com>
wrote:

> I would like to make a suggestion to the authors:
>
> OLD:
> Note that this method monitors the liveness of a node not including the
> availability of a specific IP address at that node.
>
> NEW:
> Note that this method monitors the connectivity to a system over a
> specific interface and does not verify the availability of a specific IP
> address at that system.
>
> My originally suggested text was not using the terminologies from RFC5880.
> Greg, I hope this revised text addresses your concern?
>
> Thanks,
> Ketan
>
>
> On Thu, Sep 28, 2023 at 2:43 AM Greg Mirsky <gregimirsky@gmail.com> wrote:
>
>> Hi Xiao Min,
>> thank you for your expedient response. Please find my notes below tagged
>> GIM>>.
>>
>> Regards,
>> Greg
>>
>> On Tue, Sep 26, 2023 at 6:37 PM <xiao.min2@zte.com.cn> wrote:
>>
>>> Hi Greg,
>>>
>>>
>>> Please see inline.
>>> Original
>>> *From: *GregMirsky <gregimirsky@gmail.com>
>>> *To: *Ketan Talaulikar <ketant.ietf@gmail.com>;
>>> *Cc: *肖敏10093570;rtg-bfd WG <rtg-bfd@ietf.org>;
>>> draft-ietf-bfd-unaffiliated-echo@ietf.org <
>>> draft-ietf-bfd-unaffiliated-echo@ietf.org>;
>>> *Date: *2023年09月27日 02:21
>>> *Subject: **Re: Comments on draft-ietf-bfd-unaffiliated-echo-08*
>>> Hi Ketan,
>>> Thank you for sharing your interpretation of the introduced text. I
>>> agree that your view is in line with how the scope of BFD is defined in RFC
>>> 5880:
>>>
>>>  protocol intended to detect faults in the    bidirectional path between two forwarding engines, including    interfaces, data link(s), and to the extent possible the forwarding    engines themselves
>>>
>>> But it is not clear to me how "liveness of a node" is retated to the definition above. I hope thr Authors will clarify that for me.
>>> [XM]>>> In my understanding it's the liveness of the forwarding engine.
>>> Do you expect s/the liveness of a node/the liveness of a node over the specific interface as Ketan clarified?
>>>
>>> GIM>>  I think that the Unaffiliated BFD and BFD, in general, do not
>> detect defects on the nodal level. Thus, the "liveness of a node" seems
>> inaccurate, overstretching the scope of BFD as defined in RFC 5880. I
>> suggest referring to the definition of the BFD from RFC 5880 or providing
>> an explanation of how the Unaffiliated BFD extends the defect detection
>> domain up to the nodal scope.
>>
>> Regards,
>> Greg
>>
>>>
>>> Best Regards,
>>> Xiao Min
>>>
>>>
>>> Regards,
>>>
>>> Greg
>>>
>>>
>>> On Tue, Sep 26, 2023, 09:56 Ketan Talaulikar <ketant.ietf@gmail.com>
>>> wrote:
>>>
>>>> Hi Greg,
>>>> I would read it as " ... the liveness of a node over the specific
>>>> interface ..." i.e, the node is reachable and responding over that
>>>> interface.
>>>>
>>>> Thanks,
>>>> Ketan
>>>>
>>>>
>>>> On Tue, Sep 26, 2023 at 7:16 PM Greg Mirsky <gregimirsky@gmail.com>
>>>> wrote:
>>>>
>>>>> Hi,
>>>>> as I understand it, the update assigns to the Unaffiliated BFD a new
>>>>> functionality, monitoring "the liveness of a node not including the
>>>>> availability of a specific IP address at that node". In my opinion, that
>>>>> raises some questions:
>>>>>
>>>>>    -
>>>>>
>>>>>    What is "the liveness of a node"?
>>>>>    -
>>>>>
>>>>>    When referring to the liveness of a node, does it applicable to
>>>>>    a single-box system or also to a virtual, distributed, e.g., the one using
>>>>>    the CUPS paradigm?
>>>>>    -
>>>>>
>>>>>    How the liveness of a node is derived from the functionality of a
>>>>>    single interface? Is it equally applicable regardless the interface is
>>>>>    physical or virtual?
>>>>>
>>>>> Thank you for your consideration.
>>>>>
>>>>> Regards,
>>>>> Greg
>>>>>
>>>>> On Tue, Sep 26, 2023 at 5:38 AM Ketan Talaulikar <
>>>>> ketant.ietf@gmail.com> wrote:
>>>>>
>>>>>> Thanks Xiao Min - the update looks good and addresses my comments.
>>>>>> Thanks,
>>>>>> Ketan
>>>>>>
>>>>>> On Tue, Sep 26, 2023 at 12:58 PM <xiao.min2@zte.com.cn> wrote:
>>>>>>
>>>>>>> Hi Ketan,
>>>>>>>
>>>>>>>
>>>>>>> Thank you for the suggested text, very helpful.
>>>>>>>
>>>>>>> I've just posted a new revision that incorporates all your comments.
>>>>>>> Link as below.
>>>>>>>
>>>>>>>
>>>>>>> <https://datatracker.ietf.org/doc/html/draft-ietf-bfd-unaffiliated-echo-09>
>>>>>>> https://datatracker.ietf.org/doc/html/draft-ietf-bfd-unaffiliated-echo-09
>>>>>>>
>>>>>>>
>>>>>>> <https://datatracker.ietf.org/doc/html/draft-ietf-bfd-unaffiliated-echo-09>Please
>>>>>>> see inline with [XM-2]>>>.
>>>>>>> Original
>>>>>>> *From: *KetanTalaulikar <ketant.ietf@gmail.com>
>>>>>>> *To: *肖敏10093570;
>>>>>>> *Cc: *draft-ietf-bfd-unaffiliated-echo@ietf.org <
>>>>>>> draft-ietf-bfd-unaffiliated-echo@ietf.org>;rtg-bfd@ietf.org <
>>>>>>> rtg-bfd@ietf.org>;jhaas@pfrc.org <jhaas@pfrc.org>;
>>>>>>> *Date: *2023年09月25日 15:37
>>>>>>> *Subject: **Re: Comments on draft-ietf-bfd-unaffiliated-echo-08*
>>>>>>> Hi Xiao Min,
>>>>>>> Thanks for your response. Please check inline below for further
>>>>>>> suggestions.
>>>>>>>
>>>>>>> On Mon, Sep 25, 2023 at 11:41 AM <xiao.min2@zte.com.cn> wrote:
>>>>>>>
>>>>>>>> Dear Ketan,
>>>>>>>>
>>>>>>>>
>>>>>>>> Thanks for your review and thoughtful comments.
>>>>>>>> Please see inline.
>>>>>>>> Original
>>>>>>>> *From: *KetanTalaulikar <ketant.ietf@gmail.com>
>>>>>>>> *To: *draft-ietf-bfd-unaffiliated-echo@ietf.org <
>>>>>>>> draft-ietf-bfd-unaffiliated-echo@ietf.org>;
>>>>>>>> *Cc: *rtg-bfd@ietf.org <rtg-bfd@ietf.org>;Jeffrey Haas <
>>>>>>>> jhaas@pfrc.org>;
>>>>>>>> *Date: *2023年09月22日 22:55
>>>>>>>> *Subject: **Comments on draft-ietf-bfd-unaffiliated-echo-08*
>>>>>>>> Hello Authors,
>>>>>>>>
>>>>>>>> Looks like I've missed the WGLC on this document, but nevertheless
>>>>>>>> would like to share the following comments:
>>>>>>>>
>>>>>>>> Sec 1 of the document says:
>>>>>>>>
>>>>>>>> Section 5 of [RFC5880
>>>>>>>> <https://www.ietf.org/archive/id/draft-ietf-bfd-unaffiliated-echo-08.html#RFC5880>
>>>>>>>> ] indicates that the payload of an affiliated BFD Echo packet is a
>>>>>>>> local matter and hence its contents are outside the scope of that
>>>>>>>> specification. This document, on the other hand, specifies the contents of
>>>>>>>> the Unaffiliated BFD Echo packet and what to do with them.
>>>>>>>>
>>>>>>>> However, when I go through the procedures in Section 2, there is no
>>>>>>>> description of the actual construction of the IP packet that A sends out to
>>>>>>>> B - what is the source and destination IP - or MAC addresses for that
>>>>>>>> matter? How is it that B would loop it back? I believe it is important for
>>>>>>>> the document to specify this.
>>>>>>>>
>>>>>>>> [XM]>>> This document does specify the source and destination IP,
>>>>>>>> through reference to RFC 5881. In section 2 it says
>>>>>>>>
>>>>>>>> "Regarding the selection of IP address, the rules stated in
>>>>>>>> Section 4 of [RFC5881 <https://www.rfc-editor.org/info/rfc5881>] are
>>>>>>>> applicable to the encapsulation of an Unaffiliated BFD Echo packet.
>>>>>>>> "
>>>>>>>>
>>>>>>>> In -07 version the rules of RFC 5881 were restated, however in -08
>>>>>>>> version they're removed by following the suggestion from Greg.
>>>>>>>>
>>>>>>> KT> I missed that conversation. One small suggestion so it covers
>>>>>>> not just IP address but also MAC.
>>>>>>>
>>>>>>> OLD: Regarding the selection of IP address, the rules stated in
>>>>>>> Section 4 of [RFC5881
>>>>>>> <https://www.ietf.org/archive/id/draft-ietf-bfd-unaffiliated-echo-08.html#RFC5881>
>>>>>>> ] are applicable to the encapsulation of an Unaffiliated BFD Echo
>>>>>>> packet.
>>>>>>>
>>>>>>> NEW: An Unaffiliated BFD Echo packet follows the same encapsulation
>>>>>>> rules as for a BFD Echo packet as specified in Section 4 of [RFC5881
>>>>>>> <https://www.ietf.org/archive/id/draft-ietf-bfd-unaffiliated-echo-08.html#RFC5881>
>>>>>>> ].
>>>>>>>
>>>>>>> [XM-2]>>> Accepted.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> Another important part is that normally BFD verifies the
>>>>>>>> bidirectional path, the liveness of the other endpoint, but also validates
>>>>>>>> the presence of a specific IP at that endpoint. Is that still the case when
>>>>>>>> operating in this mode? This question arises since the document talks about
>>>>>>>> liveness to servers - so is it monitoring liveness to the server host or a
>>>>>>>> specific server IP?
>>>>>>>>
>>>>>>>> [XM]>>> It's monitoring liveness to the server host, not a specific
>>>>>>>> server IP. Also note that the Unaffiliated BFD Echo can be used for
>>>>>>>> multiple use cases, in section 1 it says
>>>>>>>>
>>>>>>>> "Section 6.2.2 of [BBF-TR-146
>>>>>>>> <https://www.broadband-forum.org/technical/download/TR-146.pdf>] describes
>>>>>>>> one use case of the Unaffiliated BFD Echo. Section 2 of [
>>>>>>>> I-D.wang-bfd-one-arm-use-case
>>>>>>>> <https://datatracker.ietf.org/doc/html/draft-wang-bfd-one-arm-use-case-00>
>>>>>>>> ] describes another use case of the Unaffiliated BFD Echo."
>>>>>>>>
>>>>>>> KT> This is OK. I was looking for some text (perhaps in Section 1)
>>>>>>> that says something on the lines of ... "The Unaffiliated BFD Echo
>>>>>>> functionality only monitors liveness of the node and does not monitor the
>>>>>>> availability of a specific IP address at that node." - I believe this is an
>>>>>>> important distinction from normal BFD operations that needs to be called
>>>>>>> out. Would you agree?
>>>>>>>
>>>>>>> [XM-2]>>> Some text as you want was added to section 1.
>>>>>>>
>>>>>>>>
>>>>>>>> Finally, is it normal or natural to expect server hosts to be able
>>>>>>>> to "loop them back by normal IP forwarding"? Or does it require some
>>>>>>>> additional/special capabilities to be turned ON those hosts as hosts don't
>>>>>>>> do forwarding by default.
>>>>>>>>
>>>>>>>> [XM]>>> As I know of a deployment, there is no need to turn ON
>>>>>>>> those hosts. At the same time, it's feasible to have such a knob. Propose
>>>>>>>> to add some text as below.
>>>>>>>>
>>>>>>>> OLD
>>>>>>>>
>>>>>>>> The method for provisioning device B to loop back BFD Unaffiliated
>>>>>>>> Echo packets is outside the scope of this document.
>>>>>>>>
>>>>>>>> NEW
>>>>>>>>
>>>>>>>> There may be a knob to turn on/off the loopback of Unaffiliated BFD
>>>>>>>> Echo packets at device B. The method for provisioning device B to
>>>>>>>> loop back Unaffiliated BFD Echo packets is outside the scope of
>>>>>>>> this document.
>>>>>>>>
>>>>>>>>
>>>>>>>> KT> This is not quite where I was going. Perhaps something on the
>>>>>>> following lines?
>>>>>>> NEW:
>>>>>>> BFD Unaffiliated Echo feature depends on device B performing IP
>>>>>>> forwarding (actually IP redirect) functionality. While such functionality
>>>>>>> may normally be expected to be supported on a router, it may not be enabled
>>>>>>> on a host by default. The method for provisioning device B to loop back BFD
>>>>>>> Unaffiliated Echo packets is outside the scope of this document.
>>>>>>>
>>>>>>> [XM-2]>>> Accepted.
>>>>>>>
>>>>>>>
>>>>>>> Best Regards,
>>>>>>>
>>>>>>> Xiao Min
>>>>>>>
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Ketan
>>>>>>>
>>>>>>> Best Regards,
>>>>>>>>
>>>>>>>> Xiao Min
>>>>>>>>
>>>>>>>>
>>>>>>>> It would help if these aspects are clarified in the document.
>>>>>>>>
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Ketan
>>>>>>>>
>>>>>>>> On Thu, Jul 6, 2023 at 7:50 AM <internet-drafts@ietf.org> wrote:
>>>>>>>>
>>>>>>>>>
>>>>>>>>> A New Internet-Draft is available from the on-line Internet-Drafts
>>>>>>>>> directories. This Internet-Draft is a work item of the
>>>>>>>>> Bidirectional
>>>>>>>>> Forwarding Detection (BFD) WG of the IETF.
>>>>>>>>>
>>>>>>>>>    Title           : Unaffiliated BFD Echo
>>>>>>>>>    Authors         : Weiqiang Cheng
>>>>>>>>>                      Ruixue Wang
>>>>>>>>>                      Xiao Min
>>>>>>>>>                      Reshad Rahman
>>>>>>>>>                      Raj Chetan Boddireddy
>>>>>>>>>    Filename        : draft-ietf-bfd-unaffiliated-echo-08.txt
>>>>>>>>>    Pages           : 12
>>>>>>>>>    Date            : 2023-07-05
>>>>>>>>>
>>>>>>>>> Abstract:
>>>>>>>>>    Bidirectional Forwarding Detection (BFD) is a fault detection
>>>>>>>>>    protocol that can quickly determine a communication failure
>>>>>>>>> between
>>>>>>>>>    two forwarding engines.  This document proposes a use of the
>>>>>>>>> BFD Echo
>>>>>>>>>    where the local system supports BFD but the neighboring system
>>>>>>>>> does
>>>>>>>>>    not support BFD.  BFD Control packet and its processing
>>>>>>>>> procedures
>>>>>>>>>    can be executed over the BFD Echo port where the neighboring
>>>>>>>>> system
>>>>>>>>>    only loops packets back to the local system.
>>>>>>>>>
>>>>>>>>>    This document updates RFC 5880.
>>>>>>>>>
>>>>>>>>> The IETF datatracker status page for this Internet-Draft is:
>>>>>>>>> https://datatracker.ietf.org/doc/draft-ietf-bfd-unaffiliated-echo/
>>>>>>>>>
>>>>>>>>> There is also an htmlized version available at:
>>>>>>>>>
>>>>>>>>> https://datatracker.ietf.org/doc/html/draft-ietf-bfd-unaffiliated-echo-08
>>>>>>>>>
>>>>>>>>> A diff from the previous version is available at:
>>>>>>>>>
>>>>>>>>> https://author-tools.ietf.org/iddiff?url2=draft-ietf-bfd-unaffiliated-echo-08
>>>>>>>>>
>>>>>>>>> Internet-Drafts are also available by rsync at rsync.ietf.org:
>>>>>>>>> :internet-drafts
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>