Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41E91C14F6AB; Thu, 30 May 2024 09:28:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.095 X-Spam-Level: X-Spam-Status: No, score=-7.095 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, 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 gpIBs3g6nUdE; Thu, 30 May 2024 09:28:52 -0700 (PDT) Received: from mail-oo1-xc32.google.com (mail-oo1-xc32.google.com [IPv6:2607:f8b0:4864:20::c32]) (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 F2452C14F6A0; Thu, 30 May 2024 09:28:51 -0700 (PDT) Received: by mail-oo1-xc32.google.com with SMTP id 006d021491bc7-5b5254f9c32so599481eaf.0; Thu, 30 May 2024 09:28:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1717086530; x=1717691330; darn=ietf.org; h=references:to:cc:in-reply-to:date:subject:mime-version:message-id :from:from:to:cc:subject:date:message-id:reply-to; bh=L4JQBvWxO48GgVuWBMhOXF9pGkEY+2cYcXTwCyC/G2o=; b=DRMXuDXX+2djg/l1UTLJBme/yerQKm8ZjrxHMqKSdXoeQ7mUDO1p9ps3fEV5cT8PCh Ycb1RkSC2iDDrodic4uwdgjYzIl4iTDWQxZs0W9tLc8cAleIRdOouZTQ3FBRQ90Jvk2v PjzCu6zH5EgU7YQMpTPtiRn/zmp8/HW8nBTJiiQWYnhgY3dNdinWIyB6tBpM+7pKKEcb uy9dzcYS/dqEvcosY7m3EVSWAY7p65M6ECcHLXkToLPYcsUiZX4YObcR7Ri7eTTyV9tZ IXzgnrkJa05mRqqEyJO/LrFaGMA2cqYRKedn+1TxX74g4beb62adUu+5EoX3u6dKsTSu MtFA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1717086530; x=1717691330; h=references:to:cc:in-reply-to:date:subject:mime-version:message-id :from:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=L4JQBvWxO48GgVuWBMhOXF9pGkEY+2cYcXTwCyC/G2o=; b=IgEd782sa8VOfwCfr6/BvK9+SxDLzXHKK+cKBnx4dXeENw/qwq7iwbl3DgS44RrSHX 1S5nMj4RiQYYtmyCsGTe1qI4tGokWgG4C/fkEEtEhmCQdpLQKt4cEkpYT6xuB54rxw+3 7qux51nF7jIlaK7xDaF+/XocXPVD9gEp4H2mr9PhxzjmYbBbG4hMPflt5A+3tB3+6GLU w5jiBMdowywXcFoq4LDQLAcx1VeJRVtgvWupPKQUHKNTAQwIlwTQc6rhKOGTP8t2IClJ /51X4tBpwA2UEfIbzmRMG2QskTv7O3tA/+wtQ/sXKZNUoKzcf0AM2Ro8chInwCPKsBXS wAHg== X-Forwarded-Encrypted: i=1; AJvYcCWUISNeUVoHIXeNR7aaROD0a3EvgqrugcsJq3ko6Tn4oF3NX1OzGa2BKjHam4dbqnBkk9qLUkznqZXMaWo3nuAr8mo3yZ7GFzeAURVHsTZvLfoQjHZqCy5vC20bk0I44C3y774RhvGsStIZ50mMDT/I5NEXTurhU/USBovrEL6evsvwWfS1d7Ulhzj9 X-Gm-Message-State: AOJu0YwbOxabjJkCi13NxYXMEm+PEzr0DGy1jDXzvuFMsJVpJkPxfF7Z F87mw6aqwCR/3h3XU589zp8aeTxwVbCyzg9dyqYpmC+rrYgli36j X-Google-Smtp-Source: AGHT+IGT0Mn57v+rPQnam0SyJMAfp4hl8VH7B7B3z1FBd1kXhK/Zg7kkpTaQWig3oO4Oc6OUU7y2wQ== X-Received: by 2002:a05:6871:81f:b0:23d:4123:606e with SMTP id 586e51a60fabf-25060b6f921mr3060137fac.20.1717086530005; Thu, 30 May 2024 09:28:50 -0700 (PDT) Received: from smtpclient.apple ([2600:1700:4383:c05f:493b:7d3d:a300:705f]) by smtp.gmail.com with ESMTPSA id 586e51a60fabf-25084f8c19asm8106fac.20.2024.05.30.09.28.48 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 30 May 2024 09:28:49 -0700 (PDT) From: Bob Hinden Message-Id: <6AB0F46B-8C9F-4424-988F-2389B738046B@gmail.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_B0B8FAAC-0ECC-4863-9809-92D1AB5EA146" Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.600.62\)) Date: Thu, 30 May 2024 09:28:27 -0700 In-Reply-To: To: Warren Kumari References: <171701998302.4837.5999563238399491967@ietfa.amsl.com> <72C0C27E-CF00-48DA-BF21-6536D36FB32B@gmail.com> X-Mailer: Apple Mail (2.3774.600.62) Message-ID-Hash: FMHYNBAAH5TSE7DSC5PGFX3TBS3QJFLN X-Message-ID-Hash: FMHYNBAAH5TSE7DSC5PGFX3TBS3QJFLN X-MailFrom: bob.hinden@gmail.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-ipv6.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: Bob Hinden , 6man Chairs <6man-chairs@ietf.org>, IESG , Gorry Fairhurst , IPv6 List , draft-ietf-6man-hbh-processing@ietf.org X-Mailman-Version: 3.3.9rc4 Precedence: list Subject: =?utf-8?q?=5BIPv6=5DRe=3A_Warren_Kumari=27s_Discuss_on_draft-ietf-6man-hbh-p?= =?utf-8?q?rocessing-18=3A_=28with_DISCUSS_and_COMMENT=29?= List-Id: "IPv6 Maintenance Working Group (6man)" Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: --Apple-Mail=_B0B8FAAC-0ECC-4863-9809-92D1AB5EA146 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Warren, Thanks. We will work on some text and be back in touch. Bob=20 > On May 30, 2024, at 9:22=E2=80=AFAM, Warren Kumari = wrote: >=20 >=20 >=20 >=20 >=20 > On Wed, May 29, 2024 at 8:17 PM, Bob Hinden > wrote: >> Warren, >>=20 >> Comments below. >>=20 >> Bob & Gorry >>=20 >> On May 29, 2024, at 2:59=E2=80=AFPM, Warren Kumari via Datatracker = > wrote: >>=20 >> Warren Kumari has entered the following ballot position for = draft-ietf-6man-hbh-processing-18: Discuss >>=20 >> When responding, please keep the subject line intact and reply to all = email addresses included in the To and CC lines. (Feel free to cut this = introductory paragraph, however.) >>=20 >> Please refer to = https://www.ietf.org/about/groups/iesg/statements/handling-ballot-position= s/ for more information about how to handle DISCUSS and COMMENT = positions. >>=20 >> The document, along with other ballot positions, can be found here: = https://datatracker.ietf.org/doc/draft-ietf-6man-hbh-processing/ >>=20 >>=20 >> = ---------------------------------------------------------------------- = DISCUSS: >> = ---------------------------------------------------------------------- >>=20 >> Apologies for the late-breaking DISCUSS. >>=20 >> :-( >>=20 >>=20 >> I am unclear on the following text: >> "If a router does not process the Hop-by-Hop Options header, it MUST = forward the packet normally based on the remaining Extension Header(s) = after the Hop-by-Hop Option header (i.e., a router MUST NOT drop a = packet solely because it contains an Extension Header carrying = Hop-by-Hop options).". >>=20 >> As noted in the document, many networks do not currently follow this = behavior, and it appears that in some cases this is because the network = has chosen to filter packets with Hop-by-Hop options. It is unclear to = me if this is intended to prohibit this behavior. Operators may need to = perform this filtering -- for example, their "border" router may need to = filter packets containing HbH options to protect interior devices which = have not yet been upgraded (or similar). I'm **assuming** that you are = not trying to prohibit vendors providing the ability to filter HbH = packets, but this is not clear. >>=20 >> The draft is attempting to reduce this behavior (dropping packets = because they contain the HBH options), and to make it the default to = forward packets with HBH option headers instead of dropping the packet. >>=20 >> Note that RFC8200 doesn=E2=80=99t mention dropping packets, just not = processing the options based on local configuration: >>=20 >> NOTE: While [RFC2460] required that all nodes must examine and = process the Hop-by-Hop Options header, it is now expected that nodes = along a packet's delivery path only examine and process the Hop-by-Hop = Options header if explicitly configured to do so. >>=20 >> We do understand, that nodes will continue to do this and that an = IETF specification can=E2=80=99t change that. What do you suggest? >>=20 >> We could say something to the effect that some nodes will drop = packets containing HBH options to protect other routers who can=E2=80=99t = process them safely. Or something similar. >>=20 >=20 >=20 > Yup, that would work. Mostly I don't want people to think that the "a = router MUST NOT drop a packet solely because it contains an Extension = Header carrying Hop-by-Hop options" prohibits a router implementation is = not allowed to have a filter which matches on HbH.=20 > For example, this should still be allowed=E2=80=A6: > filter protect-old-legacy-routers { > term vendor_foo_falls_over_on_hbh { > from { > extension-header hop-by-hop; > } > then discard; > } > } >=20 >>=20 >>=20 >> I don't really understand the interplay between Section 5.1.1 = (Configuration Enabling Hop-by-Hop Header Processing) and Section 5.2 = (Hop-by-Hop Options Processing). S 5.1.1 notes that "Section 4 of = [RFC8200] allows a router to control its processing of IPv6 Hop-by-Hop = options by local configuration." and that "it is now expected that nodes = along the path only examine and process the Hop-by-Hop Options header if = explicitly configured to do so.", but Section 5.2 says: "A router SHOULD = NOT therefore be configured to process the first Hop-by-Hop option if = this adversely impacts the aggregate forwarding rate." The >> "[a] router SHOULD NOT ..." text sounds like it is trying to change = the default from "nodes along the path only examine and process the = Hop-by-Hop Options header if explicitly configured to do so" into "they = normally should, unless this adversely impacts the aggregate forwarding = rate.". If that is the intent, this should be clearer. >>=20 >> Yes, we can make that clearer, I can see how it is confusing. >>=20 >=20 >=20 >=20 > Ok, thanks. >=20 >>=20 >> Looking at the text, the second paragraph in 5.2 should probably be = moved the earlier section 5.1.1 about configuration. That paragraph is = saying don=E2=80=99t create configuration to process an option if it = can=E2=80=99t be done at full forwarding rate. Or maybe it is obvious = and should be removed. >>=20 >> Actually, I find really difficult to figure out what *exactly* has = changed from RFC8200. Section 5 says "This section describes several = changes to [RFC8200].", but the actual changes are not particularly = clear (modulo the "Option Type identifiers" changes, which are nice and = clear). >>=20 >> RFC8200 doesn=E2=80=99t say a lot about processing HBH options except = for: >>=20 >> The Hop-by-Hop Options header is not inserted or deleted, but may be = examined or processed by any node along a packet's delivery path, until = the packet reaches the node (or each of the set of nodes, in the case of = multicast) identified in the Destination Address field of the IPv6 = header. The Hop-by-Hop Options header, when present, must immediately = follow the IPv6 header. Its presence is indicated by the value zero in = the Next Header field of the IPv6 header. >>=20 >> NOTE: While [RFC2460] required that all nodes must examine and = process the Hop-by-Hop Options header, it is now expected that nodes = along a packet's delivery path only examine and process the Hop-by-Hop = Options header if explicitly configured to do so. >>=20 >> This draft is expanding on these two paragraph on how HBH options = should be processed (basically Section 5). We could add some text that = says that clearly. >>=20 >=20 >=20 > Thank you! >=20 >>=20 >> BTW, Section 6 is clear that it is updating Section 4.8 of [RFC8200]. >>=20 >>=20 >> = ---------------------------------------------------------------------- = COMMENT: >> = ---------------------------------------------------------------------- >>=20 >> Many of comments you raised below were also raised in other IESG = reviews, especially John Scudders. The authors are working on an update = that resolves them. >>=20 >=20 >=20 >=20 > Awesome, thank you! >=20 >>=20 >>=20 >> I initially had this as part of the DISCUSS, but moved it to a = comment instead. I find this bit of text ambiguous (or at least = unclear): "A router SHOULD NOT therefore be configured to process the = first Hop-by-Hop option if this adversely impacts the aggregate = forwarding rate. A router SHOULD process additional Hop-by-Hop options, = if configured to do so, providing that these also do not adversely = impact the aggregate forwarding rate." This could be read as: 1: The = router should be configured to skip the first HbH option, but should = process the additional ones. 2: The router should process the first HBH = option, but unless there is explicit configuration it should ignore the = rest. The >> "SHOULD NOT" vs "SHOULD" and double-negatives makes this hard to = read, and also makes it sounds like there are expected to be a number = configuration knobs here >> (First vs Subsequent HbH options). >>=20 >>=20 >> A similar problem occurs here: >> "If a router is unable to process any Hop-by-Hop option (or is not = configured to do so), it SHOULD behave in the way specified for an = unrecognized Option Type when the action bits were set to "00" " I'm = assuming you mean "If a router either unable (or configured) to not = process any Hop-by-Hop option ..." ? >>=20 >>=20 >> and then again here: >> "If a router is unable to process further Hop-by-Hop options (or is = not configured to do so), the router SHOULD skip the remaining options = using the >> "Hdr Ext Len" field in the Hop-by-Hop Options header. " I think that = the document would benefit greatly from some clarity here -- I'm = assuming that the intent is only a single configuration knob, but it's = really not clear... >>=20 >>=20 >> Is this duplication, or is there a meaningful difference in these two = sentences >> (destination vs host): "It is expected that the Hop-by-Hop Options = header will be processed by the destination. Hosts SHOULD process the = Hop-by-Hop Options header in received packets."? >>=20 >> I don't really understand some of the SHOULDs in Section 6 -- e.g: = "New Hop-by-Hop options SHOULD be designed to ensure the router can = process the options at the full forwarding rate." -- what router? I have = a Cisco 2509 sitting in a rack in my basement. It has very different = processing characteristics to an M40 or modern Cisco or a Linux box, and = they way that they process HbH packets differs wildly. I agree with the = sentiment, but not how this is worded. I think that this should be = clarified, or at least the SHOULD should become a should... >>=20 >> The Uppercase SHOULD/MUST was changed to lower case based on Roman = Danyliw's review. That is in -18 we just published. >>=20 >=20 >=20 >=20 > Ta! >=20 >>=20 >> Nits: >>=20 >> Thanks, we will fix.. >>=20 >=20 >=20 >=20 > Ta! >=20 > Thank you, and apologies again for the lateness of the ballot. > W >=20 >>=20 >>=20 >> 1: "The reason behind this includes:" - reasons, include? 2: "or that = forward packets" - forwards. 3: "The Router Alert Option [RFC2711] is an = exception that can result in processing in the control plane, see = Section 5.2.1." - perhaps "that can require processing by the control = plane"? Or perhaps I don't understand what this is trying to say. 4: = "When an ICMP Parameter Problem, Code 2, message is delivered to the = source, the source can become aware that at least one node on the path = has failed to recognize the option." - I don't have a suggestion, but >> "the source can become aware" make it sound like this is an = information leakage issue, and not the actual intent of the ICMP Code. = 5: "The Router Alert Option could have a potential for use with new = functions that have to be processed in the control plane." - "The Router = Alert Option could potentially be used by new functions that have to be = processed in the control plane." ? 6: "An implementation that does = recognize the Router Alert Option, SHOULD verify that a" - drop the = comma. 7: The document sets an expectation that if a packet includes a = single Hop-by-Hop option that packet will be forwarded across the = network path." - there is a random closing quote. 8: "If a subset of = packets in a flow were to include Hop-by-Hop options, this could = introduce a potential to increase the number" - could potentially ? >>=20 >=20 >=20 --Apple-Mail=_B0B8FAAC-0ECC-4863-9809-92D1AB5EA146 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Warren,

Thanks.  We will = work on some text and be back in = touch.

Bob 



On May 30, 2024, at 9:22=E2=80=AFAM, Warren Kumari = <warren@kumari.net> wrote:





On Wed, = May 29, 2024 at 8:17 PM, Bob Hinden <bob.hinden@gmail.com> = wrote:

Warren, =

Comments below.

Bob & Gorry =

On May 29, 2024, at 2:59=E2=80=AFPM, Warren = Kumari via Datatracker <noreply@ietf.org> wrote: =

Warren Kumari has entered the following ballot position for draft-ietf-6man-hbh-processing-18: Discuss

When responding, = please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.)

Please refer to https://www.ietf.org/about/group= s/iesg/statements/handling-ballot-positions/ for = more information about how to handle DISCUSS and COMMENT positions. =

The document, along with other ballot positions, can be found = here: https://datatracker.ietf.org/doc/draft-ietf-6man-hbh-processing/


----------------------------= ------------------------------------------ DISCUSS:
= ----------------------------------------------------------------------
=

Apologies for = the late-breaking DISCUSS.

:-( =


I am unclear on the = following text:
"If a router does not process the = Hop-by-Hop Options header, it MUST forward the packet normally based on the remaining Extension Header(s) after the Hop-by-Hop Option header (i.e., a router MUST NOT drop a packet solely = because it contains an Extension Header carrying Hop-by-Hop = options).".

As noted in the document, = many networks do not currently follow this behavior, and it appears that in some cases this is because the network has chosen = to filter packets with Hop-by-Hop options. It is unclear to me if this is = intended to prohibit this behavior. Operators may need to perform this filtering = -- for example, their "border" router may need to filter packets containing HbH options to protect interior devices which have not yet been upgraded (or similar). I'm **assuming** that you are not trying to prohibit vendors providing the ability to filter HbH packets, but this is not clear. =

The draft is attempting to reduce this behavior = (dropping packets because they contain the HBH options), and to make it = the default to forward packets with HBH option headers instead of = dropping the packet.

Note that RFC8200 doesn=E2=80=99t = mention dropping packets, just not processing the options based on local = configuration:

NOTE: While [RFC2460] required that all nodes = must examine and process the Hop-by-Hop Options header, it is now expected that nodes along a packet's delivery path only examine and process the Hop-by-Hop Options header if explicitly configured to do so. =

We do understand, that nodes will continue to do this and = that an IETF specification can=E2=80=99t change that. What do you = suggest?

We could say something to the effect that some nodes = will drop packets containing HBH options to protect other routers who = can=E2=80=99t process them safely. Or something = similar.


Yup, that would work. Mostly I don't want people to = think that the "a router MUST NOT drop a packet solely because it = contains an Extension Header carrying Hop-by-Hop options" prohibits a = router implementation is not allowed to have a filter which matches on = HbH. 
For example, this should still be = allowed=E2=80=A6:
filter protect-old-legacy-routers = {
    term vendor_foo_falls_over_on_hbh = {
        from = {
         &nbs= p;  extension-header = hop-by-hop;
        = }
        then = discard;
    = }
}



I don't really understand = the interplay between Section 5.1.1 (Configuration Enabling Hop-by-Hop Header Processing) and Section 5.2 (Hop-by-Hop = Options Processing). S 5.1.1 notes that "Section 4 of [RFC8200] allows a router = to control its processing of IPv6 Hop-by-Hop options by local = configuration." and that "it is now expected that nodes along the path only examine and = process the Hop-by-Hop Options header if explicitly configured to do so.", but = Section 5.2 says: "A router SHOULD NOT therefore be configured to process the first Hop-by-Hop option if this adversely impacts the aggregate forwarding = rate." The
"[a] router SHOULD NOT ..." text sounds like = it is trying to change the default from "nodes along the path only examine and process the Hop-by-Hop = Options header if explicitly configured to do so" into "they normally should, = unless this adversely impacts the aggregate forwarding rate.". If that is the = intent, this should be clearer.

Yes, we can = make that clearer, I can see how it is = confusing.



Ok, = thanks.


Looking at the text, the second = paragraph in 5.2 should probably be moved the earlier section 5.1.1 = about configuration. That paragraph is saying don=E2=80=99t create = configuration to process an option if it can=E2=80=99t be done at full = forwarding rate. Or maybe it is obvious and should be removed. =

Actually, I find really difficult to figure out = what *exactly* has changed from RFC8200. Section 5 says "This section describes several changes to = [RFC8200].", but the actual changes are not particularly clear (modulo the "Option = Type identifiers" changes, which are nice and clear). =

RFC8200 doesn=E2=80=99t say a lot about = processing HBH options except for:

The Hop-by-Hop Options = header is not inserted or deleted, but may be examined or processed by any node along a packet's delivery path, until the packet reaches the node (or each of the set of nodes, in the case of multicast) identified in the Destination Address field of the IPv6 header. The Hop-by-Hop Options header, when present, must immediately follow the IPv6 header. Its presence is indicated by the value zero in the Next Header field of the IPv6 header.

NOTE: = While [RFC2460] required that all nodes must examine and process the Hop-by-Hop Options header, it is now expected that nodes along a packet's delivery path only examine and process the Hop-by-Hop Options header if explicitly configured to do so. =

This draft is expanding on these two paragraph on how HBH = options should be processed (basically Section 5). We could add some = text that says that = clearly.


Thank you!


BTW, Section 6 is clear that it is = updating Section 4.8 of [RFC8200].


----------------------------= ------------------------------------------ COMMENT:
= ----------------------------------------------------------------------
=

Many of = comments you raised below were also raised in other IESG reviews, = especially John Scudders. The authors are working on an update that = resolves = them.


Awesome, thank = you!



I initially had this as = part of the DISCUSS, but moved it to a comment instead. I find this bit of text ambiguous (or at least unclear): "A router = SHOULD NOT therefore be configured to process the first Hop-by-Hop option if this adversely impacts the aggregate forwarding rate. A router SHOULD = process additional Hop-by-Hop options, if configured to do so, providing that = these also do not adversely impact the aggregate forwarding rate." This could = be read as: 1: The router should be configured to skip the first HbH option, but = should process the additional ones. 2: The router should process the first HBH = option, but unless there is explicit configuration it should ignore the rest. = The
"SHOULD NOT" vs "SHOULD" and double-negatives makes = this hard to read, and also makes it sounds like there are expected to be a number configuration = knobs here
(First vs Subsequent HbH = options).


A similar problem occurs = here:
"If a router is unable to process any Hop-by-Hop = option (or is not configured to do so), it SHOULD behave in the way specified for an unrecognized = Option Type when the action bits were set to "00" " I'm assuming you mean "If a = router either unable (or configured) to not process any Hop-by-Hop option ..." = ?


and then again here: =
"If a router is unable to process further Hop-by-Hop = options (or is not configured to do so), the router SHOULD skip the remaining options using = the
"Hdr Ext Len" field in the Hop-by-Hop Options = header. " I think that the document would benefit greatly from some clarity here -- I'm assuming = that the intent is only a single configuration knob, but it's really not = clear...


Is this duplication, or is = there a meaningful difference in these two sentences
= (destination vs host): "It is expected that the Hop-by-Hop Options = header will be processed by the destination. Hosts SHOULD process the Hop-by-Hop = Options header in received packets."?

I don't really understand = some of the SHOULDs in Section 6 -- e.g: "New Hop-by-Hop options SHOULD be designed to ensure the router can process = the options at the full forwarding rate." -- what router? I have a Cisco = 2509 sitting in a rack in my basement. It has very different processing characteristics to an M40 or modern Cisco or a Linux box, and they way = that they process HbH packets differs wildly. I agree with the sentiment, but = not how this is worded. I think that this should be clarified, or at least = the SHOULD should become a should...

The Uppercase = SHOULD/MUST was changed to lower case based on Roman Danyliw's review. = That is in -18 we just = published.



Ta!


Nits: =

Thanks, we will = fix..


Ta!

Thank you, = and apologies again for the lateness of the = ballot.
W



1: "The reason behind this = includes:" - reasons, include? 2: "or that forward packets" - forwards. 3: "The Router Alert Option [RFC2711] is an exception that can result in processing in the control plane, see Section 5.2.1." - perhaps "that can require processing by the control plane"? Or perhaps I don't understand = what this is trying to say. 4: "When an ICMP Parameter Problem, Code 2, = message is delivered to the source, the source can become aware that at least one = node on the path has failed to recognize the option." - I don't have a = suggestion, but
"the source can become aware" make it = sound like this is an information leakage issue, and not the actual intent of the ICMP Code. 5: "The Router Alert = Option could have a potential for use with new functions that have to be = processed in the control plane." - "The Router Alert Option could potentially be used = by new functions that have to be processed in the control plane." ? 6: "An implementation that does recognize the Router Alert Option, SHOULD = verify that a" - drop the comma. 7: The document sets an expectation that if a = packet includes a single Hop-by-Hop option that packet will be forwarded across = the network path." - there is a random closing quote. 8: "If a subset of = packets in a flow were to include Hop-by-Hop options, this could introduce a = potential to increase the number" - could potentially ?



= --Apple-Mail=_B0B8FAAC-0ECC-4863-9809-92D1AB5EA146--