Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFB23130EC1; Tue, 26 Feb 2019 03:55:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.69 X-Spam-Level: X-Spam-Status: No, score=-1.69 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=eci365.onmicrosoft.com 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 to4iNFWCgW8b; Tue, 26 Feb 2019 03:55:10 -0800 (PST) Received: from mail1.bemta26.messagelabs.com (mail1.bemta26.messagelabs.com [85.158.142.115]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C03EC126C01; Tue, 26 Feb 2019 03:55:09 -0800 (PST) Received: from [85.158.142.193] (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256 bits)) by server-4.bemta.az-b.eu-central-1.aws.symcld.net id 43/D9-03001-B19257C5; Tue, 26 Feb 2019 11:55:07 +0000 X-Brightmail-Tracker: H4sIAAAAAAAAA1WTaUwTQRTHmd3tdjGsjK3Ks0GNNR6gW6lXirf Gg5AYTfxgYmh0CyttLEvttrFqVAweETTeiggpEKqCR6TiETQKKBGqqaISbxFRo2jwIvFGu2zx +DL5zfu//zuSGYbUdNA6RvC4BKfI2/V0D2rsoGlmThfnTknIyppk+rL1Hmm611JHmToLC0jTi dsB2vTAV6aapkoqLf1KJB05VYaS8vdvoueTi1Q20ZLpWaKyVm/Zo3b4SpCnKhBQZ6GO7SgH9W AoXELC6Wcb1PJFg3cSkJ+3l1QujxHszq6hc1AkQ+PJ4D/6uIt741GQG9zX5SBxC4LSqpNIFrR 4GXxtbkJKkh28e3LDhtHw5eFhQmYKD4Hj34+FmGFYbIYfbfPlsAZPgKuNDaTMkXgiFNUojHBf +Bw41mUlcQw8eO7tYsAYSi/cIBXuA69bO1UKD4K8JwVqhfvDLW8uUngutG+5i+S2gAdD5SuzP D7gVgRNZU1hbzxc++APe3VQ31inUpIeRcOliuxwYzvktR8MN46FM76zaiUpSENwdwNStkmF+o JPlLKBBZpfFIenGADl21ooxXCThM2Nu9Q7UHz+P9spLELB+/0qmVncCxoOPKeU+EgoOv+RVng EHCp+Q3bz9epW4t94EVKXo0SL05ZudWXwNjtnTEjgjMYx3FjOmDjewK/iLAbBzaUKosvJh1QD v0IySCszUu1pBlFw+VHo1aUtp66cQ+82p9eifgyh78OOGepO0fS0ZKattPKSdbHTbRekWhTLM Hpgy4eFtF5OIV3wLLXZQ0+3WwYmSt+bHSrLrOTgMyRbuiIFUCJTXdJSSDKVzS9DZ5V8aigxUx R0Mew32YBlg9Ut/inX/Rluof46LYsiIiI0UQ7BmWFz/a+3oRgG6bXsHLlKlE10/enaFhqICA1 0+bUkD+Ti/0q6LLTxxaO1nff31Wgjjjylg+vO/dyLJ/m/v12z4/q1SiZ44MZ77ZyRKW1xh4kL a4noqTmra+/MmO7bFfupYeG7cetyCL8nFb4Nq2SEqzO9s+u9yaN9vmRHh/uj+Xjh+khN9sCdd VHDp3DeeeY7NSOYBehidO7TxqKp8Y5Z1op27td5x2Q9JVl5YzzplPjfGeNNlAcEAAA= X-Env-Sender: Alexander.Vainshtein@ecitele.com X-Msg-Ref: server-10.tower-238.messagelabs.com!1551182103!1895924!1 X-Originating-IP: [52.33.64.93] X-SYMC-ESS-Client-Auth: mailfrom-relay-check=pass X-StarScan-Received: X-StarScan-Version: 9.31.5; banners=ecitele.com,-,- X-VirusChecked: Checked Received: (qmail 8065 invoked from network); 26 Feb 2019 11:55:05 -0000 Received: from us-west-2b.mta.dlp.protect.symantec.com (HELO EUR04-VI1-obe.outbound.protection.outlook.com) (52.33.64.93) by server-10.tower-238.messagelabs.com with AES256-SHA256 encrypted SMTP; 26 Feb 2019 11:55:05 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ECI365.onmicrosoft.com; s=selector1-ecitele-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=7VS765X9TZzcQfV7vWjOdV3SO0AVQT2mnifx9e2FrTw=; b=FTODW78llzFQ20gaQbVNihbGsDt3mmN7dF7Vp6iaOEt43e58ZkEuCtuJ6tvBdC/GHhGjOX/3lmrg7xq9KsgUGtZChaJKf4d/Lpyg8pUdQN52tWU6qJtHtCFUfZ7DQYEM6fcuqNT6HzceXpPXeb5YnvGPVWFQZihmEhdV7hfttOo= Received: from AM0PR03MB3828.eurprd03.prod.outlook.com (52.135.146.159) by AM0PR03MB3668.eurprd03.prod.outlook.com (52.134.81.143) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1643.20; Tue, 26 Feb 2019 11:55:01 +0000 Received: from AM0PR03MB3828.eurprd03.prod.outlook.com ([fe80::cd69:f7a:ee65:6435]) by AM0PR03MB3828.eurprd03.prod.outlook.com ([fe80::cd69:f7a:ee65:6435%5]) with mapi id 15.20.1643.019; Tue, 26 Feb 2019 11:55:01 +0000 From: Alexander Vainshtein To: "adrian@olddog.co.uk" CC: "mpls-chairs@ietf.org" , "draft-nainar-mpls-rfc8287-len-clarification@ietf.org" , 'Loa Andersson' , "mpls@ietf.org" Thread-Topic: [mpls] Pipelining the inevitable adoption poll on draft-nainar-mpls-rfc8287-len-clarification Thread-Index: AdTNxUJnQ9WDFgDvRYi52BMJf0SHhwAAFUPw Date: Tue, 26 Feb 2019 11:55:00 +0000 Message-ID: References: <033901d4cdc5$4640f2e0$d2c2d8a0$@olddog.co.uk> In-Reply-To: <033901d4cdc5$4640f2e0$d2c2d8a0$@olddog.co.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.234.241.1] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: e967948b-09d9-4e21-518f-08d69be13cec x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600127)(711020)(4605104)(4618075)(2017052603328)(7153060)(7193020); SRVR:AM0PR03MB3668; x-ms-traffictypediagnostic: AM0PR03MB3668: x-ms-exchange-purlcount: 1 x-microsoft-exchange-diagnostics: =?us-ascii?Q?1; AM0PR03MB3668; 23:vwOkArT09ZQ42FVzw/9zA1OVCgeHMxxyLVkUpGWfI?= =?us-ascii?Q?Os8LI3lTx5gMi9peWJwEkqVJWp1GXuCRR9ldo76bvBX5k8zE5IIwWYKjEXOd?= =?us-ascii?Q?HWX/FY8G+NRd55W9wJR7w5iztoeq7SfiPN0i9WuOr+UrFZ9NAbzuFkc4ICt2?= =?us-ascii?Q?jN5Q1cTy+/UGl6UgyzElEPcYMtH+k84FN7RQT/+NK/rXOyXKvT41a0JHGkAg?= =?us-ascii?Q?1Zvtu0rQYXLgt037nodlwQWSF7ia1dC88Rl68xwtKgmqV2rVb8C9MkirvxGT?= =?us-ascii?Q?SqUP1sOHxeVOnMOc0CVE5PRDG+jB72pqjiQrFFW8TRnKh+WxPHlOLQOBKCFH?= =?us-ascii?Q?WCwkuJMvreNJrdUuBq+2yY1LKS9jZv8X+5scUddIl+38sS2nEfBlCF5Y1YZN?= =?us-ascii?Q?bRdMwzslMiKgPCBZbZQzIcDjUv1L8/3f49ZaE5Djp2aGvJjW9ErfBSMgU0ni?= =?us-ascii?Q?27dnr5DJWa2fUmr1C14sRgNAllptDihWEn3c+hTYiBr6fPhp6cHv5atJ4fOa?= =?us-ascii?Q?FBoXNuE4SbbK+zd46p1r4igail4N/aDnA6TJj7dYqGinz5/UYK/eNzjd3kYt?= =?us-ascii?Q?RmHIpC4iyffScBKEbQeKwSR7nd7Kh+AjJbl4SlUdkA+F1S8bb91iLkNZDzRP?= =?us-ascii?Q?eXWZuAu7XOFGpP19gtqW2vS/HxGARupKWINZHMQT4tanYJ34e8YaW2AviBmh?= =?us-ascii?Q?MN2IUsd/wfKr18cDj52++Gf2sRLXyJQohf0HbjTfCZXDcK6T817LQ7n+0xQh?= =?us-ascii?Q?JRi2pI82oLG8kIpcKPI3TO+VlMlP+pxhlInzjKs62bDrLasUr7gpG2ASbeXf?= =?us-ascii?Q?DHzxqRagJ/Ley4me6kfU56R2l8xVYqchAbr8RqV7hJZw/2tv8PDsqmNfWSvR?= =?us-ascii?Q?zoBTf0pG+HvlZ6h2Wf+EJ+/JM3ZBj9IIcMi46FweK5rF/vCIOTBcGLjtxGoe?= =?us-ascii?Q?uUIVy3sujIPBjCqthZ19sCCaP1UYiNa188SUH6IWiM73kBt/ZeTk3HV7uQ1N?= =?us-ascii?Q?4kmfFlpPW80x+XyBy8IIiBdEKPgPSSzceSArzeD1haEQJH+pgoFktti9LOit?= =?us-ascii?Q?zAfeHrSc1MN77lMaixG/oHpV52/fz0UHpYoaUzbHU0PaRIpZRPgTDcVl8XXw?= =?us-ascii?Q?HzDTzEXgF5BZr2Os+E8O4VgvZbjryXpeZthsepEohnZuHZHOZIPuOxKYruZ6?= =?us-ascii?Q?qD0QNTIu/neRa+G7RQSl4Vj3U7kaPerdYtJVEfVDZUbJir/Xa9AWVLa+pTzh?= =?us-ascii?Q?VP/Rb9VkMLyYcSysziqr05gDvS3JG6+0TFiKZ1vNU7PevLT2C7qM/pfzvGfG?= =?us-ascii?Q?3UFhN3q9CTMFsoMMbMtI2aWAn190t2Vi4C0ycPy7SY4LwWKS1OHltvtp9iRR?= =?us-ascii?Q?OzkSOK/KdWSGwz1ZfOeQAf3X28NmXt4hnUyRVe3apjTy22YhjyO95LRm+vy7?= =?us-ascii?Q?374fclSJ1oPR5MMsMb5hCljMoCvW4rNzpRa1FIkjZt9gVWA11D2cJPd8QynX?= =?us-ascii?Q?nHgovPGZxb/LtEqz0x5tHjCvTivu332rMM=3D?= x-microsoft-antispam-prvs: x-forefront-prvs: 096029FF66 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(136003)(366004)(396003)(376002)(346002)(39860400002)(13464003)(51444003)(199004)(189003)(486006)(53936002)(478600001)(72206003)(966005)(5660300002)(6436002)(2906002)(33656002)(6116002)(5640700003)(790700001)(3846002)(54896002)(6306002)(55016002)(229853002)(9686003)(14454004)(6916009)(236005)(25786009)(81166006)(7736002)(8676002)(1730700003)(66066001)(81156014)(11346002)(54906003)(476003)(74316002)(4326008)(2351001)(97736004)(106356001)(186003)(105586002)(316002)(256004)(14444005)(71190400001)(606006)(6246003)(26005)(2501003)(52536013)(68736007)(71200400001)(8936002)(76176011)(446003)(7696005)(99286004)(102836004)(86362001)(53546011)(6346003)(6506007); DIR:OUT; SFP:1102; SCL:1; SRVR:AM0PR03MB3668; H:AM0PR03MB3828.eurprd03.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: ecitele.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: 4RXCLtIjFFcA7NfL8JIbBfT6YzuJTe4g/c2hEQLXxNB1QQsmD6658EwJxI5Sv9l4oa1GXYcQDWUmOXEQt9PX2S/91z5WNyTmJl3oetDnsUlT+Vu+YfhFwRzKGt+U/8Q+ZOubNGR/sjIkle3beh/ge/n7cSKedFVOUQMdUJhQt5x9beT/M8pi3TNd6iWcSMb2+UAYIg/GNH6374ynWEptRYXKZ5LlEN3bwVeT8eRGj7K4tb27pyceZL6JVcCoIiXE8H8T1baTyaDqUS+6mbucQg+tcisj21sjVPDuQ99qx2AMdu2JB96cYKBcSbOmWev/+HBrMZCjSEt85rs3mLF2tsXSAQixUhr1gJ56Y1G9F4nf+n/oe69mTS9r8QRSTpJdAymS6ra1j5fZAf/GSEirxJ9KX6lNNeEq3GnpPrFXtP0= Content-Type: multipart/alternative; boundary="_000_AM0PR03MB3828A9DDF9FCBEECADFCE4359D7B0AM0PR03MB3828eurp_" MIME-Version: 1.0 X-OriginatorOrg: ecitele.com X-MS-Exchange-CrossTenant-Network-Message-Id: e967948b-09d9-4e21-518f-08d69be13cec X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Feb 2019 11:55:00.9979 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2c514a61-08de-4519-b4c0-921fef62c42a X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR03MB3668 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [mpls] Pipelining the inevitable adoption poll on draft-nainar-mpls-rfc8287-len-clarification X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Feb 2019 11:55:14 -0000 --_000_AM0PR03MB3828A9DDF9FCBEECADFCE4359D7B0AM0PR03MB3828eurp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Adrian, Just to make it clear, I have filed the erratum on RFC 8287 (which, I bel= ieve is the singular form while errata is plural) that has been rejected b= y Deborah because "This change requires an update to the RFC, requires con= sensus". I agree that we could make the draft somewhat shorter - but not by much: = the part that looks too long to you takes roughly 2 pages out of 5.5. The added value is that the current version means that the implementer doe= s not have to do any length calculations (that always carry with them the = risk of miscalculations): everything is spelled out in the same way as it = is in RFC 8029. I also think that when the "reserved" field is explicitly defined as follo= wing: Reserved The Reserved field MUST be set to 0 when sent and MUST be ignored on receipt. it is somewhat different to distinguish it from a "true" MBZ field: What's= in a name? And I do not think that this field has been intended for the future sub-TL= Vs since it itself is part of a sub-TLV. The bottom line: I think that the draft is ready for adoption by the WG. I= f the WG, following adoption, requests to make it shorter, we can do that.= Regards, Sasha Office: +972-39266302 Cell: +972-549266302 Email: Alexander.Vainshtein@ecitele.com -----Original Message----- From: mpls On Behalf Of Adrian Farrel Sent: Tuesday, February 26, 2019 1:20 PM To: 'Loa Andersson' ; mpls@ietf.org Cc: mpls-chairs@ietf.org; draft-nainar-mpls-rfc8287-len-clarification@ietf= .org Subject: [mpls] Pipelining the inevitable adoption poll on draft-nainar-mp= ls-rfc8287-len-clarification Hi, Since Loa is polling for IPR, I suspect an adoption poll is likely to foll= ow. I know this document arises from confusion during interop, and I have some= sympathy with people who find RFCs hard to parse. I also understand that = the AD rejected fixing this through an Errata Report, and so the only opti= on is to publish an RFC (the motivation here appears to be that=20consensu= s is needed for the resolution). IMHO, 8029 is clear on how to set the length of a TLV or sub-TLV. The sub-= TLV length includes all of the fields of the sub-TLV, but not any trailing= padding. The TLV length includes all of the sub-TLV padding. Thus, the only issue I can see here was that there was confusion about whe= ther fields marked as "Reserved" formed part of the sub-TLVs. The only rea= son they would be, would be to allow for future extensions, otherwise they= would just be padding. Clearly (according to this document) they were intended to be part of the = sub-TLVs (for extensions). That is inconsistent with how 8029 is written, = but since 8287 uses "Reserved" not "MBZ" it is acceptable if that is reall= y want people want to achieve (i.e., that is the consensus decision that i= s needed). Doesn't that mean that the *only* text needed is to say... "Fields marked 'Reserved' in sub-TLVs defined in RFC 8287 are an integral = part of the sub-TLVs and MUST be accounted in computation of the length of= the sub-TLVs."? The current draft seems like a lot of text to make that clarification. Thanks, Adrian -----Original Message----- From: mpls > On Behalf= Of Loa Andersson Sent: 26 February 2019 07:09 To: mpls@ietf.org Cc: mpls-chairs@ietf.org; draft-nainar-mpls-rfc8287-len-clarification@ietf.org Subject: [mpls] IPR poll on draft-nainar-mpls-rfc8287-len-clarification Working Group, authors, We have started to prepare draft-nainar-mpls-rfc8287-len-clarification for working group adoption, prior to the wgap we need to do an IPR poll. This mail starts this IPR poll. Are you aware of any IPR that applies to draft-nainar-mpls-rfc8287-len-cla= rification? If so, has this IPR been disclosed in compliance with IETF IPR rules (see = RFCs 3979, 4879, 3669 and 5378 for more details). There no IPR disclosures against draft-nainar-mpls-rfc8287-len- clarificat= ion. If you are listed as a document author or contributor please respond to th= is email regardless of whether or not you are aware of any relevant IPR. *= The response needs to be sent to the MPLS WG mailing list.* The document w= ill not advance to the next stage until a response has been received from = each author and contributor. If you are on the MPLS WG email list but are not listed as an author or co= ntributor, then please explicitly respond only if you are aware of any IPR= that has not yet been disclosed in conformance with IETF rules. /Loa mpls wg co-chair -- Loa Andersson email: loa@pi.nu Senior MPLS Expert Bronze Dragon Consulting phone: +46 739 81 21 64 _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls __________________________________________________________________________= _ This e-mail message is intended for the recipient only and contains inform= ation which is=20 CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have rece= ived this=20 transmission in error, please inform us by e-mail, phone or fax, and then = delete the original=20 and all copies thereof. __________________________________________________________________________= _ --_000_AM0PR03MB3828A9DDF9FCBEECADFCE4359D7B0AM0PR03MB3828eurp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Adrian,

Just to make it clear, I have filed the errat= um  on RFC 8287 (which, I believe is the singular form while errata is plural) that has been rejected by Deborah because “= This change requires an update to the RFC= , requires consensus”.

 

I agree that we could make the draft somewhat sh= orter  - but not by much: the part that looks too long to you takes r= oughly 2 pages out of 5.5.

The added value is that the current version mean= s that the implementer does not have to do any length calculations (that a= lways carry with them the risk of miscalculations): everything is spelled = out in the same way as it is in RFC 8029.

 

I also think that when the “reserved”= ; field is explicitly defined as following:

<quote>

   Reserved

 

      The Reserved = field MUST be set to 0 when sent and MUST be ignored

=

      on receipt.

<end quote>

it is somewhat different to distinguish it from = a “true” MBZ field: What’s in a name?

 

And I do not think that this field has been inte= nded for the future sub-TLVs since it itself is part of a sub-TLV.

 

The bottom line: I think that the draft is ready= for adoption by the WG. If the WG, following adoption, requests to make i= t shorter, we can do that.

 

Regards,

Sasha

 

Office: +972-39266302

Cell:      +972-549= 266302

Email:   Alexander.Vainshtein@ecitele.= com

 

 

-----Original Message-----
From: mpls <mpls-bounces@ietf.org> On Behalf Of Adrian Farrel
Sent: Tuesday, February 26, 2019 1:20 PM
To: 'Loa Andersson' <loa@pi.nu>; mpls@ietf.org
Cc: mpls-chairs@ietf.org; draft-nainar-mpls-rfc8287-len-clarification@ietf= .org
Subject: [mpls] Pipelining the inevitable adoption poll on draft-nainar-mp= ls-rfc8287-len-clarification

 

Hi,

 

Since Loa is polling for IPR, I suspect an adopt= ion poll is likely to follow.

 

I know this document arises from confusion durin= g interop, and I have some sympathy with people who find RFCs hard to pars= e. I also understand that the AD rejected fixing this through an Errata Re= port, and so the only option is to publish an RFC (the motivation here appears to be that consensus is needed for th= e resolution).

 

IMHO, 8029 is clear on how to set the length of = a TLV or sub-TLV. The sub-TLV length includes all of the fields of the sub= -TLV, but not any trailing padding. The TLV length includes all of the sub= -TLV padding.

 

Thus, the only issue I can see here was that the= re was confusion about whether fields marked as "Reserved" forme= d part of the sub-TLVs. The only reason they would be, would be to allow f= or future extensions, otherwise they would just be padding.

 

Clearly (according to this document) they were i= ntended to be part of the sub-TLVs (for extensions). That is inconsistent = with how 8029 is written, but since 8287 uses "Reserved" not &qu= ot;MBZ" it is acceptable if that is really want people want to achieve (i.e., that is the consensus decision that is needed).

 

Doesn't that mean that the *only* text needed is= to say...

"Fields marked 'Reserved' in sub-TLVs defin= ed in RFC 8287 are an integral part of the sub-TLVs and MUST be accounted = in computation of the length of the sub-TLVs."?

 

The current draft seems like a lot of text to ma= ke that clarification.

 

Thanks,

Adrian

 

-----Original Message-----

From: mpls <mpls-bounces= @ietf.org> On Behalf Of Loa Andersson

Sent: 26 February 2019 07:09

To: mpls@ietf.org

Cc: mpls-chairs@ietf.org;

draft-nainar-mpls-rfc8287-len-clarification@ietf.org

Subject: [mpls] IPR poll on draft-nainar-mpls-rf= c8287-len-clarification

 

Working Group, authors,

 

We have started to prepare draft-nainar-mpls-rfc= 8287-len-clarification

for working group adoption, prior to the wgap we= need to do an IPR poll.

 

This mail starts this IPR poll.

 

Are you aware of any IPR that applies to draft-n= ainar-mpls-rfc8287-len-clarification?

 

If so, has this IPR been disclosed in compliance= with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details)= .

 

There no IPR disclosures against draft-nainar-mp= ls-rfc8287-len- clarification.

 

If you are listed as a document author or contri= butor please respond to this email regardless of whether or not you are aw= are of any relevant IPR. *The response needs to be sent to the MPLS WG mai= ling list.* The document will not advance to the next stage until a response has been received from each author and= contributor.

 

If you are on the MPLS WG email list but are not= listed as an author or contributor, then please explicitly respond only i= f you are aware of any IPR that has not yet been disclosed in conformance = with IETF rules.

 

 

/Loa

  mpls wg co-chair

--

 

 

Loa Andersson      = ;            &= nbsp;     email: loa@pi.nu=

Senior MPLS Expert

Bronze Dragon Consulting    =          phone: +46 739 81 21 = 64

 

_______________________________________________<= o:p>

mpls mailing list

mpls@ietf.org=

https://www.i= etf.org/mailman/listinfo/mpls

 

_______________________________________________<= o:p>

mpls mailing list

mpls@ietf.org=

https://www.i= etf.org/mailman/listinfo/mpls


__________________________________________________________________________= _

This e-mail message is intended for the recipient only and contains inform= ation which is
CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have rece= ived this
transmission in error, please inform us by e-mail, phone or fax, and then = delete the original
and all copies thereof.
__________________________________________________________________________= _
--_000_AM0PR03MB3828A9DDF9FCBEECADFCE4359D7B0AM0PR03MB3828eurp_--