[Idr] Re: Mohamed Boucadair's Yes on draft-ietf-idr-nhc-05: (with COMMENT)

["Scudder, John" <[e-mail]>]

Hi Med,

Thanks for your careful review. I’ve responded point by point in-line. I just uploaded version 06 which includes changes based on your and Éric’s input.

> On Jun 2, 2026, at 2:59 AM, Mohamed Boucadair via Datatracker <[e-mail]> wrote:
> 
> Mohamed Boucadair has entered the following ballot position for
> draft-ietf-idr-nhc-05: Yes
> 
> 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://urldefense.com/v3/__https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/__;!!NpxR!gYPV-2-zAY8lyGxtSiPCmoYcdxRYE_dL7FFTT64oKXETa4XfEyEdZFS_b-cykOJaWvYd2Q4eqvVWifI$  
> for more information about how to handle DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ietf-idr-nhc/__;!!NpxR!gYPV-2-zAY8lyGxtSiPCmoYcdxRYE_dL7FFTT64oKXETa4XfEyEdZFS_b-cykOJaWvYd2Q4e_2Zh-mE$ 
> 
> 
> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> Hi Bruno, Kireeti, Serge, Satya, John, Kevin, and Bin,
> 
> Thank you for the effort put in this specification. It was an interesting read
> to go through all the one decade I-Ds branches that lead to this effort.
> 
> The document is well-written and well-articulated, although there is a mix of
> protocol specifications and operational considerations (incremental deployment,
> configuration knobs, when special care is needed from those who deploy, log
> abnormal behavior, etc.) but that’s fine as far as these are there.
> 
> Please find some comments, fwiw:
> 
> # Initial values

For clarity, I believe this is about the IANA considerations section.

> I suggest we clarify the following:
> 
> ## Add a mention that entries can be modified (deleted or content altered).
> This is to have a provision for some of these I-Ds to change the description if
> they want so or update the reference if any of these I-Ds make it to an RFC.

I don’t think this is required, if I understand you correctly. It’s always possible for an IANA registry to be updated, assuming the appropriate steps are followed for the registry policy. The policy of this registry is FCFS and the change controller IETF, so I think that leaves maximum ability for later RFCs to modify the registry.

If I’ve misunderstood your point please LMK.

> ## The table does not track the document/event that led to a registration. For
> example, there is no visible information in the registry that indicates 1-2-4-5
> are registered by this doc. Maybe add a note column to disclose that?

I take your point. I kind of hate to clutter the registry for all time with an extra column. What if we provided two references in the “reference” column, with the second reference being the present document? I know I’ve seen this practice in other registries, and I’ve made the change in 06.

> ### Do we envisage in future having attributes that can be deprecated? If so,
> should that indication be supported by the registry (that is, add a status
> column)?

In my experience there’s no need to have a separate column in order to deprecate code points. There are many examples in https://www.iana.org/assignments/bgp-parameters/bgp-parameters.xhtml#bgp-parameters-2, for instance DPA.

> # Mismatch
> 
> CURRENT:
>       0                   1                   2                   3
>       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>      |   Address Family Identifier   |     SAFI      | Next Hop Len  |
>      +-------------------------------+---------------+---------------+
>      |                                                               |
>      ~             Network Address of Next Hop (variable)            ~
>      |                                                               |
>      +---------------------------------------------------------------+
>      |                                                               |
>      ~                 Characteristic TLVs (variable)                ~
>      |                                                               |
>      +---------------------------------------------------------------+
> 
>                            Figure 1: NHC Format
> 
>   The meanings of the header fields (Address Family Identifier, SAFI or
>   Subsequent Address Family Identifier, Length of Next Hop, and Network
>   Address of Next Hop) are as given in Section 3 of [RFC4760].
> 
> ## Mismatch between the figure and description for “Next Hop Len”.
> 
> ## Please note that RFC4760 uses “Length of Next Hop Network Address”, not
> “Length of Next Hop” or “Next Hop Len”.

Thanks. 

NEW:
The meanings of the header fields (Address Family Identifier, Subsequent Address Family Identifier ("SAFI"), Length of Next Hop Network Address ("Next Hop Len"), and Network Address of Next Hop) are as given in Section 3 of {{RFC4760}}.

> # Applicable only for NHC-aware routers
> 
> CURRENT:
>   When a BGP speaker receives a BGP route that includes the NHC, it
>   MUST compare the address given in the header portion of the NHC and
>   illustrated in Figure 1 to the next hop of the BGP route.
> 
> This seems to be assumed, but it is better to make it explicit this (and all
> Section 2.3) is discussing the behavior of NHC-aware routers.

There are 19 instances of “BGP speaker” in the document. Rather than hunt down and change each of them to “BGP speaker that supports this specification”, I propose to include this as Section 1.2:

```
## Terminology

Throughout this document, "NHC" is used both to refer to the Next Hop Dependent Characteristics Attribute itself and, when used adjectivally, to the framework and individual characteristics carried within that attribute.

Throughout this document, requirements directed at a "BGP speaker" mean a BGP speaker that supports this specification. A BGP speaker can be said to support this specification if support is present in the implementation, and is enabled (or, not disabled) in its configuration. 
```

You will see I also moved a sentence out of paragraph 2 of §1, since now we have a better home for it and it improves the flow of the introduction to not interrupt it with a parenthetical comment.

> # NHC Information
> 
> CURRENT:
>   Since the NHC is intended chiefly for conveying information about
>   forwarding plane features, it needs to be regenerated whenever the
>   BGP route's next hop is changed.
> 
> ## There is nothing in the document that actually constrains the nature of
> information that can be conveyed in an NHC. The allocation FCFS policy won’t
> help rationalize that space.

I think this is OK. The text is correct as written: it’s our *intention* that the NHC be used *chiefly* for what it says, that is different from saying that it must not or even should not be used for other applications.

> ## Having a more constrained range would be my favorite here (minimum Expert
> Review range).

I’m not sure what you’re getting at. You want to make the entire range of code points smaller, for example one byte instead of two bytes? You want to reserve a different subrange as Expert Review and apply a stricter entry gate to it? I don’t think this is needed, see above.

> 
> # “potentially useful”
> 
> CURRENT:
>   The NHC signals
>   potentially useful information related to the forwarding plane
>   features, so it is desirable to make it transitive to ensure
> 
> ## I’m sure there is a reasoning behind that subtle mention, but this raises
> the questions as why one would announce something that isn’t useful?
> 
> ## Shouldn’t we simply say:
> 
> NEW:
>   The NHC signals
>   information related to the forwarding plane
>   features, so it is desirable to make it transitive to ensure

Done.

> # Characteristic Code
> 
> CURRENT:
>   Characteristic Code: a two-octet unsigned integer that indicates the
>   type of characteristic advertised and unambiguously identifies an
>   individual characteristic.
> 
> ## Shouldn’t the description include a mention about “forwarding” as that is
> the intended use?

I don’t think so; see my reply above. 

> ## I suggest to add a pointer to the registry
> 
> NEW:
>  Values are taken from the registry (Section 4).

Done.

> ## As I’m there, the document is silent about sending reserved values
> 
> Consider adding text such as the following here or in Section 2.2:
> 
> NEW:
>  By default, characteristics with Code set to a reserved value (Section 4)
>  MUST NOT be used when sending an NHC.
> 
> “by default” is on purpose as this allows to relax the rule for experimentation
> or testing.
> 
> Alternatively, we may only cover 0 and 65535 cases:
> 
> NEW:
>  Characteristics with Code set to 0 and 65535 MUST NOT be used when sending an
>  NHC.

I’m not absolutely opposed to this but it seems unnecessary — saying “don’t send codes you don’t have a registration for” is awfully close to saying “don’t write bugs”. This is not something we generally do in our specs and I’m hesitant to add line count for it. For now, I have left it out.

> # Characteristic Value
> 
> CURRENT:
>   Characteristic Length: a two-octet unsigned integer that indicates
>   the length, in octets, of the Characteristic Value field.  A length
>   of 0 indicates that the Characteristic Value field is zero-length,
>   i.e., it has a null value.
> 
>   Characteristic Value: a variable-length field.  It is interpreted
>   according to the value of the Characteristic Code.
> 
> Should Characteristic Value description say that it includes a non-null value
> to avoid having two ways to encode null values?

Hmm. What would it say? When I started trying to revise, I came up with 

```
Characteristic Value: a variable-length field.  If Characteristic Length is non-zero, then this field is a non-null value, interpreted according to the value of the Characteristic Code. 
```

I’m not sure this is necessary since it comes directly after the Characteristic Length description which tells us almost the same information. For now I have left it as it was.

> # Redundant behavior
> 
> 2.2.1
> 
>   To mitigate this problem, if a BGP speaker constructs a route whose
>   next hop has no global part, it MUST include a BGPID TLV (Section 3).
> 
> Vs.
> 
> 3.2
>   when a route
>   includes only a link-local address and no global address, the BGPID
>   MUST be included.
> 
> I would keep the normative language in one single place.

Fair enough. I’m pretty sure this redundancy was introduced in response to a request from a past reviewer, but we can square the circle by changing the 3.2 language from “MUST be” to “is included, per the requirement in Section 2.2.1”. I’ve done this.

> # Picky
> 
> ## Peer vs Peers
> 
> A BGP speaker may have several peers.
> 
> OLD:
>   RFC 5492 allows a BGP speaker to advertise its capabilities to its
>   peer.  When a route is propagated beyond the immediate peer, it is
> 
> NEW:
>   RFC 5492 allows a BGP speaker to advertise its capabilities to its
>   peers.  When a route is propagated beyond an immediate peer, it is
> 
> or
> 
> NEW2:
>   RFC 5492 allows a BGP speaker to advertise its capabilities to a
>   peer. When a route is propagated beyond an immediate peer, it is
> 
> A similar construct is also present in the introduction.

Fair enough. I chose the “to a peer” version.

> ## Multiple ASNs
> 
> A speaker may have multiple ASNs.
> 
> OLD:
>  AS Number: The Autonomous System Number [RFC6793]
> 
> NEW:
>  AS Number: An Autonomous System Number [RFC6793]

I chose to leave this as written, judging that taken in context it is not confusing. In my view, the Platonic BGP speaker has a single AS, and the cases where a single speaker has multiple ASes is a bit of a perversion ;-) and I’m happier to keep the short part of the description simple. For context, here’s the whole thing:

```
AS Number: The Autonomous System Number [RFC6793] of the route's sender. In cases where the sender might represent different Autonomous System Numbers to different peers (for example, [RFC5065], [RFC7705]), the value used is the one that was in the sender's BGP OPEN to the peer concerned.
```

ISTM that the “in cases where” sentence makes it clear.

> ## It is the ASN that is carried in the attribute
> 
> OLD: Autonomous System carried in the BGPID.
> 
> NEW: Autonomous System Number carried in the BGPID.

Very true. Done.

Regards,

—John