Re: [spring] Question about SRv6 Insert function

"Pablo Camarillo (pcamaril)" <pcamaril@cisco.com> Thu, 19 December 2019 11:52 UTC

Return-Path: <pcamaril@cisco.com>
X-Original-To: spring@ietfa.amsl.com
Delivered-To: spring@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFE0B1200FE for <spring@ietfa.amsl.com>; Thu, 19 Dec 2019 03:52:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.497
X-Spam-Level:
X-Spam-Status: No, score=-14.497 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=Hc5R6ef6; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=Lw5+sEHm
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mavM45MZ7acu for <spring@ietfa.amsl.com>; Thu, 19 Dec 2019 03:52:54 -0800 (PST)
Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A3841200F9 for <spring@ietf.org>; Thu, 19 Dec 2019 03:52:53 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=41472; q=dns/txt; s=iport; t=1576756373; x=1577965973; h=from:to:subject:date:message-id:references:mime-version; bh=rjgMbeJjjcT9U/CPGXJFjtQ6cI3bm1Jttfu+MdgrzCw=; b=Hc5R6ef6w+58cv9fbRdDDDa4Drh1apoGZKy7rYLEOMjr9PWULygmXFxw 5d/nCsQsCN+bIA2NzoG74SwGWPbmbAMi9JRBJwAKbzat3poQBtQKh+wgR 6b4cl/ZMzZwlgWDiB1GcNo/+QlLMXtE/Uiflg8b7lu3otlAXsvd24aL1r w=;
IronPort-PHdr: =?us-ascii?q?9a23=3AupGrUREnPj8nHK9nYZ3Vu51GYnJ96bzpIg4Y7I?= =?us-ascii?q?YmgLtSc6Oluo7vJ1Hb+e4z1Q3SRYuO7fVChqKWqK3mVWEaqbe5+HEZON0pNV?= =?us-ascii?q?cejNkO2QkpAcqLE0r+eebhZikzBsVGfFRk5Hq8d0NSHZW2ag=3D=3D?=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CLAQBOY/td/4cNJK1kGgEBAQEBAQE?= =?us-ascii?q?BAQMBAQEBEQEBAQICAQEBAYF8gR4vUAVsWCAECyqEBoNGA4pzToIRiV2OKoF?= =?us-ascii?q?CgRADUAQJAQEBDAEBGAEMCAIBAYRAAheCBCQ4EwIDDQEBBAEBAQIBBQRthTc?= =?us-ascii?q?MhV4BAQEBAgEBARAICQoTAQEsDAsEAgEIEQMBAQEBIAcDAgICHwYLFAkIAgQ?= =?us-ascii?q?BEggagwGBeU0DDiABDqFRAoE4iGF1gTKCfgEBBYUfDQuCDAMGgTaMGRqBQT+?= =?us-ascii?q?BEUeCTD6CG0kBAQIBgS0BDAYBBxoVCAEHBQEJgloygiyNKhwvgkKFViSJPI4?= =?us-ascii?q?sMUMKgjWHMYU4hQWEQYJDh3mEQYtUjReBN4hSghyPYwIEAgQFAg4BAQWBaSJ?= =?us-ascii?q?ncXAVO4JsUBgNjRIMF4NQhRSFP3QBgSeNHA4XghsBAQ?=
X-IronPort-AV: E=Sophos;i="5.69,331,1571702400"; d="scan'208,217";a="688372925"
Received: from alln-core-2.cisco.com ([173.36.13.135]) by rcdn-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 19 Dec 2019 11:52:52 +0000
Received: from XCH-RCD-005.cisco.com (xch-rcd-005.cisco.com [173.37.102.15]) by alln-core-2.cisco.com (8.15.2/8.15.2) with ESMTPS id xBJBqpYj020988 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 19 Dec 2019 11:52:52 GMT
Received: from xhs-rcd-002.cisco.com (173.37.227.247) by XCH-RCD-005.cisco.com (173.37.102.15) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 19 Dec 2019 05:52:51 -0600
Received: from xhs-rtp-002.cisco.com (64.101.210.229) by xhs-rcd-002.cisco.com (173.37.227.247) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 19 Dec 2019 05:52:50 -0600
Received: from NAM04-SN1-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-002.cisco.com (64.101.210.229) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Thu, 19 Dec 2019 06:52:50 -0500
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=d4SuKn6P/QUV/wKttmMaqNx5nC02nFwZ85JDcTmfvFZ53Q9OTY7YpR6tQVbWeKMkxyhMdenWRw7SpYMFE2l0A4lu/mbRuuv0tUGfvl/ah6gefJOhfvX2+GQLUFJeRX8AzT8rqT0nnjdRywJGB0g+7uSy9/zpzK1FrHxrdnSvoPJcxYawj/h7ydGqv7roZlSC4qQHfknCjqPbTL0dncz/QxDxnar5gn4H9JWm0/U3SSCpbHAAMIDl0zpTgNu2BQW9xQBLg/1HLJhsqwuB9ITXw2uZ+M7037+j65JU68fkzRNjfjixWrxY+7wpqJfLoM9F3ZC112HmXe3yo6UPMe37cw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=rjgMbeJjjcT9U/CPGXJFjtQ6cI3bm1Jttfu+MdgrzCw=; b=JAngPhKFaG/FtBYO5e+5ZLDLaPftA7MV8yOs3T+4K8gH4A9KmnV06CxfDEhgr3aPhOe/JjO8BfRSRg16c3BgZxRaoWqXHzhLwSzqZ+blZbtMhriOkkL7SoMSWw6nWb0RZ82YyfSRgFMfLvJVa7brKXpiqQoGQqvpX2dVoDe5dGQ2Sb6MEVf7E0Z2edNRlRsfgGLadouVbj9ghUt/9bi9tjZsJTEWvwkA/XVU3zs/Kh6Wm34b1loWCRzieCnmApN7+DDWPjjbnWIV4Uq6eOq9T2Zk0hOqPyH9FJnly/GTIGTzCKMawJnB2IT+/89Z3omtWxBwL4JV4fxuJ7oBIo6cBw==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=rjgMbeJjjcT9U/CPGXJFjtQ6cI3bm1Jttfu+MdgrzCw=; b=Lw5+sEHmQvmKRgc57O7+JhTswygt6F54OGAlJIL5/gChHdfog/ar3+g9MgFkZD6vTmjsgRUgAx8jqxZ3OkIGvOLPr0G6ZsNz301cD9kEyWQTLdvK5ddI6hSZ7wRBFwoBs+EhRRwWfXmG/6ZZ5VxZR0j+2GTnk0mIRxovYLXVTPg=
Received: from BN6PR11MB1363.namprd11.prod.outlook.com (10.173.33.7) by BN6PR11MB1955.namprd11.prod.outlook.com (10.175.98.9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2559.14; Thu, 19 Dec 2019 11:52:49 +0000
Received: from BN6PR11MB1363.namprd11.prod.outlook.com ([fe80::3113:31:4a84:cc4d]) by BN6PR11MB1363.namprd11.prod.outlook.com ([fe80::3113:31:4a84:cc4d%6]) with mapi id 15.20.2559.016; Thu, 19 Dec 2019 11:52:49 +0000
From: "Pablo Camarillo (pcamaril)" <pcamaril@cisco.com>
To: Alexandre Petrescu <alexandre.petrescu@gmail.com>, "spring@ietf.org" <spring@ietf.org>
Thread-Topic: [spring] Question about SRv6 Insert function
Thread-Index: AQHVXxis/gF6F9KunkOxVqkDbflgtacT7YMwgAFf0ICAA0V6AIABQWiAgANe6oCAlbReAIABVZmAgAAm8oCAAOg1gIAABUaAgAEzGwCABvg3gIADHtWR
Date: Thu, 19 Dec 2019 11:52:49 +0000
Message-ID: <MWHPR11MB1374842A5AFCB0EFD5AECFA0C9530@MWHPR11MB1374.namprd11.prod.outlook.com>
References: <HK0PR03MB3970C6DCC635E7CD802D65FDFCBD0@HK0PR03MB3970.apcprd03.prod.outlook.com> <BYAPR05MB54636A2332FED916A26A6F14AEBD0@BYAPR05MB5463.namprd05.prod.outlook.com> <3e31873a-278a-2154-0e71-4d820bba323d@gont.com.ar> <4012D854-2F10-4476-951D-FFFE73C5083C@gmail.com> <cb2f56f8-acdc-d68d-0878-9609cb3d7b1b@gont.com.ar> <28214_1567694772_5D711FB4_28214_238_1_53C29892C857584299CBF5D05346208A48BFA9F3@OPEXCAUBM43.corporate.adroot.infra.ftgroup> <129bbb32-0f14-b799-430c-8f76fb6b1279@gont.com.ar> <1824_1575998223_5DEFD30F_1824_112_1_53C29892C857584299CBF5D05346208A48D24EBD@OPEXCAUBM43.corporate.adroot.infra.ftgroup> <4384c08a-65f5-dbfb-85c7-8365feba9662@gmail.com> <11783_1576056453_5DF0B685_11783_221_1_53C29892C857584299CBF5D05346208A48D261E9@OPEXCAUBM43.corporate.adroot.infra.ftgroup> <260f6f3c-e3cc-e174-1782-456df7cded86@gmail.com> <8683D672-1A59-4253-AC46-14DD2D8C8B14@cisco.com>, <35c4119f-1d46-0220-d7e4-168b27beb782@gmail.com>
Accept-Language: en-US
Content-Language: en-GB
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/10.20.0.191208
authentication-results: spf=none (sender IP is ) smtp.mailfrom=pcamaril@cisco.com;
x-originating-ip: [2001:420:44da:1250:2dac:e1f3:236d:5679]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 57a22ae8-52de-4802-f0c6-08d78479f8d3
x-ms-traffictypediagnostic: BN6PR11MB1955:
x-microsoft-antispam-prvs: <BN6PR11MB1955540A498A67E555EFC8FAC9520@BN6PR11MB1955.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 0256C18696
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39860400002)(346002)(366004)(136003)(396003)(376002)(13464003)(189003)(199004)(316002)(81156014)(8676002)(81166006)(2906002)(186003)(64756008)(66556008)(478600001)(6506007)(110136005)(53546011)(30864003)(6512007)(66476007)(8936002)(66446008)(966005)(76116006)(5660300002)(86362001)(91956017)(66946007)(6486002)(66574012)(9686003)(71200400001)(33656002)(52536014); DIR:OUT; SFP:1101; SCL:1; SRVR:BN6PR11MB1955; H:BN6PR11MB1363.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: jKfJkVpyC5xXwb4/SHB9Y6hUDXc+NXeIRkGF6xPBcn662ebchTaPIXz2KbhbUD6AwzJuxy8uQkTvThd2SgkU8OBnbeAAimnn25f8hlTUwDclMwsnxuvJn1K/jqpfWpPTzVQLV3RzIjI9pzm7wN0T77OjDqw6KrJSnXHL566y+KwU+nKkn5shn78CeujHPIVO7z2bjxfxRj/oI9Wf4i9Ap4hqcVpXEAWi5BL9ytKkGtAaNlP0cMneztSIbi6tGvMSV9MbO3uaQugYtBbdmxPdogutFJTGIftiJioHwtoVgpSjIphE45DASC9ewImaCUGVbqyhOikrAs/XSAgv9+YD+/h2waOpp/Y45ctbG4ZMqGaKtAadAJOjUKTklD2TR/+yBE57Kw1Ikr7atrTa5pZhVKjbKwjPu6WmuK4QWIx6Z+jfH3YMOGMXpjwv921WMV+I6AP/bN4KQved16B9zXIHLEM6vwkzbVZyJXV2V4BIqTfh+fmsL2BQSnl59pGooB1UAp8VUM1XYcZY7y7QOGAL6qmhENf4CXXb8tbcYD5EKg0=
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_MWHPR11MB1374842A5AFCB0EFD5AECFA0C9530MWHPR11MB1374namp_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 57a22ae8-52de-4802-f0c6-08d78479f8d3
X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Dec 2019 11:52:49.5003 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: Xy83HVb5Vsm5iKAlsgIW78ym0VIKFdfD1vaJqLVLPS/Wf9G2yMmq3bw8EyBJGA+nL0iVyOcgK9B0aD3ncev2xQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR11MB1955
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.37.102.15, xch-rcd-005.cisco.com
X-Outbound-Node: alln-core-2.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/spring/TeSnDq2TkQrpk8DR5NGoPucDtBg>
Subject: Re: [spring] Question about SRv6 Insert function
X-BeenThere: spring@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" <spring.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/spring>, <mailto:spring-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/spring/>
List-Post: <mailto:spring@ietf.org>
List-Help: <mailto:spring-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/spring>, <mailto:spring-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 19 Dec 2019 11:52:58 -0000

Hi Alex.

Please see inline.

Many thanks,
Pablo.

________________________________
From: Alexandre Petrescu <alexandre.petrescu@gmail.com>
Sent: Monday, December 16, 2019 3:31 PM
To: Pablo Camarillo (pcamaril) <pcamaril@cisco.com>om>; ipv6@ietf.org <ipv6@ietf.org>
Subject: Re: [spring] Question about SRv6 Insert function

Hi, SPRINGers,

This is my first post to this list.

This is about draft-ietf-spring-srv6-network-programming-06
more precisely the T.Encaps section 5.2.

Le 11/12/2019 à 21:05, Pablo Camarillo (pcamaril) a écrit :
> Alex,
>
> The precise definition T.Encaps is done in section 5.1 [5.2 now] of
> draft-ietf-spring-srv6-network-programming-06. If you have any
> comment on such definition please let me know -on a separate thread
> and directed to SPRING mailer-.

Thank you for the reply.

Please make the T.Encaps part of the draft easier for me to read, e.g.:
-expand what it means 'S01'; is it 'Step 01', like in BASIC programming
  language?

PC: Same format as in other documents (e.g. SRH).

-clarify that the original packet in transit is not modified upon
  transition (modulo the Hop Limit field and the Segments Left field if
  present); new packet is created to carry the original packet - yes.

PC: I have added a paragraph in the latest version of the draft to capture your point. See rev07. Many thanks.

-clarify what it means 'a packet (A, S2)(S3, S2, S1; SL=1)'; because it
  is confusing in several ways; (A,S2) invites to think it is src and dst
  addresses, but their place is switched (the normal order is Source,
  Destination).  S in 'S2' might mean a Source Address but also might
  mean a Segment ID, or a Destination address.  Confusion should be
  avoided, at least in my mind.

PC: This is explained in the terminology section of the draft (with a detailed example).

Alex

>
> Many thanks, Pablo.
>
> -----Original Message----- From: ipv6 <ipv6-bounces@ietf.org> on
> behalf of Alexandre Petrescu <alexandre.petrescu@gmail.com> Date:
> Wednesday, 11 December 2019 at 10:46 To: "ipv6@ietf.org"
> <ipv6@ietf.org> Subject: Re: [spring] Question about SRv6 Insert
> function
>
>
>
> Le 11/12/2019 à 10:27, bruno.decraene@orange.com a écrit :
>> Brian, Pablo
>>
>> Please see inline (multiple points)
>>
>>> From: Brian E Carpenter [mailto:brian.e.carpenter@gmail.com]
>>> Sent: Tuesday, December 10, 2019 8:36 PM To: DECRAENE Bruno
>>> TGI/OLN; Fernando Gont Cc: Ron Bonica; spring@ietf.org;
>>> 6man@ietf.org; Suresh Krishnan;
>>> draft-voyer-6man-extension-header-insertion;
>>> draft-ietf-spring-srv6-network-programming Subject: Re: [spring]
>>> Question about SRv6 Insert function
>>>
>>> Bruno,
>>>
>>> On 11-Dec-19 06:17, bruno.decraene@orange.com wrote:
>>>> Fernando,
>>>>
>>>>> From: Fernando Gont [mailto:fernando@gont.com.ar] Sent:
>>>>> Monday, December 9, 2019 9:54 PM
>>>>>
>>>>> On 5/9/19 09:46, bruno.decraene@orange.com wrote: [....]
>>>>>>>
>>>>>>> Since there have been plenty of attempts to do EH
>>>>>>> insertion or leave the IPv6 standard ambiguous in this
>>>>>>> respect, and the IETF has had consensus that EH insertion
>>>>>>> is not allowed, I think it would be bad, wastefull,
>>>>>>> tricky, and even dangerous to let a document go through
>>>>>>> the whole publication process, and just rely on the AD
>>>>>>> to keep the "DISCUSS" button pressed.
>>>>>>
>>>>>> draft-ietf-spring-srv6-network-programming has a normative
>>>>>> reference to [I-D.voyer-6man-extension-header-insertion]
>>>>>> https://tools.ietf.org/html/draft-ietf-spring-srv6-network-programming-01#section-13.1
>
>>>>>>
>>>>>
>>>>>> As such, from a process standpoint, it would not going to
>>>>>> be published before
>>>>>> [I-D.voyer-6man-extension-header-insertion] be itself
>>>>>> published as RFC. And from its name, the latter is intended
>>>>>> to be discussed and within control of the 6MAN WG. So I
>>>>>> don't think that we can say that it "just rely on the AD to
>>>>>> keep the "DISCUSS" button pressed."
>>>>>
>>>>> Yes, it is just relying on that.
>>>>
>>>> Situation has changed since this email: the network programming
>>>> draft has now removed text related to SRH insertion. Please
>>>> comment on the text if you see text related to SRH insertion.
>>>
>>> For example:
>>> https://tools.ietf.org/html/draft-ietf-spring-srv6-network-programming-05#section-8.2
>
>>>
>
>> Quoting the draft for everyone to read " Every  node is expected to
>> advertise via BGP-LS its SRv6 capabilities (e.g. how many SIDs it
>> can insert as part of a T.Encaps behavior)"
>>
>>
>> This is related to T.Encaps which is using IPv6 (outer)
>> encapsulation.
>
> The term 'IPv6 encapsulation' has a somehow precise meaning, see
> below a citation from an RFC.
>
> Do you mean that T.Encaps 'encapsulates' just the SRv6 header or the
> entire IPv6 packet that contains the SRv6 header?
>
> RFC2473:
>> IPv6 encapsulation consists of prepending to the original packet
>> an IPv6 header and, optionally, a set of IPv6 extension headers
>> (see Fig.3), which are collectively called tunnel IPv6 headers.
>
> Alex
>
>> - If you believe that T.Encaps is unclear on that, please comment
>> on its text. [1] - If the issue is the use of the term 'insert',
>> which is too close to the 'SRH insertion issue', I'm personally
>> fine with using a different term. E.g. "add". Please propose any
>> term which suits you [1]. That been said, I hope that we are not in
>> a situation where words are being forbidden.
>>
>> [1] Preferably in the related thread, in order to help everyone
>> (all WG members, chairs, shepherds, ADs, IESG)  to be able to track
>> all comments. As we'll likely be in a situations where the number
>> of emails may be consequent
>>
>>> Why would draft-voyer-6man-extension-header-insertion exists if
>>> the SRH proponents do not intend to perform SRH insertion?
>>
>> As of today, the question been asked is a WG last call on
>> draft-ietf-spring-srv6-network-programming. If you want to secure
>> that SRH insertion is not used in the document, please comment as
>> part of its last call.
>>
>> That been said, thanks to your comment, I've seen an unused
>> reference for [I-D.filsfils-spring-srv6-net-pgm-insertion]  that
>> needs to be removed
>>
>> --Bruno
>>
>>
>>>
>>> Brian
>>>
>>>>
>>>>> A question of you as a chair: does the wg you chair publish
>>>>> documents based on current specs (or at the very least based
>>>>> on  changes that are going to happen in the near term as a
>>>>> result of *existing and proven consensus*), or does spring
>>>>> ship documents that implicitly betting on changes that have
>>>>> no consensus?
>>>>
>>>> In general, I don't see the benefit of sending a draft which we
>>>> expect would never progress to RFC. So this would not be my
>>>> preferred path. However, I guess that as always, there are
>>>> exceptions and I'm not a priori aware of a process forbidding
>>>> this. As of today, I'd rather not spend time on this
>>>> hypothetical case.
>>>>
>>>>> The former is how I expect WGs to operate. The later shows a
>>>>> clear path to a huge pile of documents stuck at IESG review,
>>>>> simply because so later in the process folks found out that
>>>>> the document turns out to violate existing specs. With the
>>>>> risk of an AD pressing "YES", and hence IETF has been
>>>>> circumvented.
>>>>
>>>> While IESG processing is beyond my paycheck (literally ;-) ), I
>>>> trust the IESG. And I don't see a reason to doubt a priori. And
>>>> even in this case, there may be a possibly to fetch back the
>>>> document from the RFC editor queue.
>>>>
>>>> In short: very hypothetic case and beyond my hat. As of today,
>>>> I'd propose that we work on the text of the document.
>>>>
>>>> Thank you, --Bruno
>>>>
>>>>> Thanks, -- Fernando Gont e-mail: fernando@gont.com.ar ||
>>>>> fgont@si6networks.com PGP Fingerprint: 7809 84F5 322E 45C7
>>>>> F1C9 3945 96EE A9EF D076 FFF1
>>>>>
>>>>>
>>>>>
>>>>
>>>> _________________________________________________________________________________________________________________________
>
>>>>
>>>
>>>> Ce message et ses pieces jointes peuvent contenir des
>>>> informations confidentielles ou privilegiees et ne doivent
>>>> donc pas etre diffuses, exploites ou copies sans autorisation.
>>>> Si vous avez recu ce message par erreur, veuillez le signaler a
>>>> l'expediteur et le detruire ainsi que les pieces jointes. Les
>>>> messages electroniques etant susceptibles d'alteration, Orange
>>>> decline toute responsabilite si ce message a ete altere,
>>>> deforme ou falsifie. Merci.
>>>>
>>>> This message and its attachments may contain confidential or
>>>> privileged information that may be protected by law; they
>>>> should not be distributed, used or copied without
>>>> authorisation. If you have received this email in error, please
>>>> notify the sender and delete this message and its attachments.
>>>> As emails may be altered, Orange is not liable for messages
>>>> that have been modified, changed or falsified. Thank you.
>>>>
>>>> --------------------------------------------------------------------
>
>>>>
>>> IETF IPv6 working group mailing list
>>>> ipv6@ietf.org Administrative Requests:
>>>> https://www.ietf.org/mailman/listinfo/ipv6
>>>> --------------------------------------------------------------------
>
>>>>
>>>
>>
>> _________________________________________________________________________________________________________________________
>
>>
>
>> Ce message et ses pieces jointes peuvent contenir des informations
>> confidentielles ou privilegiees et ne doivent donc pas etre
>> diffuses, exploites ou copies sans autorisation. Si vous avez recu
>> ce message par erreur, veuillez le signaler a l'expediteur et le
>> detruire ainsi que les pieces jointes. Les messages electroniques
>> etant susceptibles d'alteration, Orange decline toute
>> responsabilite si ce message a ete altere, deforme ou falsifie.
>> Merci.
>>
>> This message and its attachments may contain confidential or
>> privileged information that may be protected by law; they should
>> not be distributed, used or copied without authorisation. If you
>> have received this email in error, please notify the sender and
>> delete this message and its attachments. As emails may be altered,
>> Orange is not liable for messages that have been modified, changed
>> or falsified. Thank you.
>>
>> --------------------------------------------------------------------
>
>>
> IETF IPv6 working group mailing list
>> ipv6@ietf.org Administrative Requests:
>> https://www.ietf.org/mailman/listinfo/ipv6
>> --------------------------------------------------------------------
>
>>
>
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list ipv6@ietf.org Administrative
> Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>
>