[prev in list] [next in list] [prev in thread] [next in thread]
List: ipng
Subject: Re: [IPv6] Robert Wilton's Discuss on draft-ietf-6man-rfc6874bis-05: (with DISCUSS)
From: Erik Kline <ek.ietf () gmail ! com>
Date: 2023-07-18 22:36:07
Message-ID: CAMGpriV2=4euZQKd7t_vK6OMst0KgcLGvU7WoDi_EM+GKpbW7A () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
Rob,
I concur with Brian here.
Perhaps one source of difficulty here is that the zone id is logically
internal to a node and is never externally observable (I can't think of any
field in any transmitted datagram where it appears).
If your node displays different interface indexes for SNMP vs YANG vs CLI
then some, or even none, of those are usable by any RFC {3493, 3542} style
API (IPv6 BSD Sockets API). If your node has no such API for "apps" on the
node to use then I suppose it doesn't have to worry about consistent scope
identifiers.
-ek
On Tue, Jun 20, 2023 at 2:49 PM Brian E Carpenter <
brian.e.carpenter@gmail.com> wrote:
> Hi Rob,
>
> On 21-Jun-23 03:54, Rob Wilton (rwilton) wrote:
> > Hi Brian,
> >
> > I don't regard interfaces on network devices as inherently having a
> numeric identifier.
>
> But that *is* the model described in RFC 4007. If there are devices whose
> o/s doesn't support the model of a Zone ID plus a numeric index, then they
> are basically out of scope for this draft. Would it help if we added a
> clear statement to that effect?
>
> > Many devices currently expose interfaces via the SNMP IfMib, and hence
> they assign and expose an IfIndex associated with the interface, but that
> identifier logically only exists/belongs to the SNMP management domain.
> E.g., a different management protocol could easily use a different format
> for interface identifiers, and e.g., in the case of YANG and CLI, they do.
>
> I'm a bit surprised, but I believe that is orthogonal to the current
> draft, which does really rely on the identifier and index described in RFC
> 4007 as part of the IPv6 addressing model. From the comments made by Jürgen
> Schönwälder, it seemed that the index in management data models was
> identical to the index in the RFC 4007 model, but that the difficulties
> arose in the names. Doesn't the -08 draft make that clear and show how to
> avoid the issue by using the numeric index?
>
> >
> > But I wonder if the issue that I have here, is that there should just be
> a more cleanly specified definition of what a zone-id is and what it is
> not. I.e., I think that a zone-id for an interface is a device unique
> arbitrary string that conforms to the ABNF in your draft. It could be an
> interface name, or a translated interface name, or a numeric id (that
> ideally would match the Ifindex if possible).
>
> That's undoubtedly true, but fixing it is a major piece of work. Our goal
> here is to allow browsers and HTTP servers to handle what is currently
> implemented for the common operating systems, to meet increasingly urgent
> needs. Can we not proceed now by making it clear that this issue is out of
> scope?
>
> > Hence, I wonder whether it wouldn't be cleaner for this document to
> formally update RFC 4007 to redefine what a zone-id is:
> > - redefine the allowed character set for zone-ids (section 11.2),
> restricting it to the allowed URI character set.
> > - indicate that it is RECOMMENDED for interfaces names be used
> directly as the zone-id for interface zones, if the interface name directly
> conform to the URI character set.
> > - for interface names don't conform then (e.g., for most network
> devices) :
> > - a device unique translated form of the interface name SHOULD be
> used that conforms to the zone-id character set (e.g., perhaps convert
> GigabitEthernet1/0/0/0.1 to ethernet1-0-0-0.1)
> > - a device unique numeric identifier for the interface MAY be used
> as the zone-id instead of an end-user meaningful string. If the device
> supports the SNMP IfMIB, and a numeric zone identifier is desired, then the
> numeric identifier SHOULD match the IfMIB Ifindex for the interface.
> > - the interface zone-id should be explicitly displayed in network
> management models and APIs in cases where it is helpful to support
> management operations (i.e., to solve your copy and paste requirement).
> >
> > Is something like this a plausible way forward?
>
> Personal opinion: Yes, RFC 4007 needs significant revision. No, this draft
> is not the place to do it - it would be a long discussion. I think that it
> would be at least a year before anything stable comes out of 6MAN that also
> meets the needs of network management data models. Meanwhile, anyone who
> needs to use a complete link-local address in a browser is stuck.
>
> Regards
> Brian
>
> >
> > Regards,
> > Rob
> >
> >
> >> -----Original Message-----
> >> From: Brian E Carpenter <brian.e.carpenter@gmail.com>
> >> Sent: 20 June 2023 00:59
> >> To: Rob Wilton (rwilton) <rwilton@cisco.com>; The IESG <iesg@ietf.org>
> >> Cc: draft-ietf-6man-rfc6874bis@ietf.org; 6man-chairs@ietf.org;
> ipv6@ietf.org
> >> Subject: Re: Robert Wilton's Discuss on draft-ietf-6man-rfc6874bis-05:
> (with
> >> DISCUSS)
> >>
> >> Rob,
> >>
> >> I'm replying to your original DISCUSS for simplicity. We are now at
> version 08
> >> of the draft, and waiting for the next step from the IESG.
> >>
> >> In summary, the changes since the IESG review are:
> >>
> >> - Added NMEA use case.
> >> - Clearly explained cut-and-paste requirement.
> >> - * Clarified character set restrictions and the applicability of
> numeric
> >> identifiers as a work-around.
> >> - * Updated ABNF to require lower case (due to host component case
> >> normalization)
> >> - Mentioned .local as another case of locally significant URIs.
> >> - Expanded text on handling of zone ID at server.
> >> - Added discussion of CORS.
> >> - Noted parsing fragility re % sign.
> >> - Noted potential exposure of MAC addresses in zone IDs
> >>
> >> The changes marked with an asterisk are particularly relevant to your
> DISCUSS.
> >> Unfortunately the general rules about URIs make it impossible to be
> case-
> >> sensitive or to use certain symbols.
> >> (Operating systems such as Linux introduce their own restrictions,
> too.) To
> >> resolve this, it is necessary to use numeric interface indexes instead
> of "human-
> >> readable" names for those cases. That really is the best we can do.
> >>
> >> We look forward to your comments.
> >>
> >> Regards
> >> Brian Carpenter + co-authors
> >>
> >> On 16-Mar-23 11:44, Robert Wilton via Datatracker wrote:
> >>> Robert Wilton has entered the following ballot position for
> >>> draft-ietf-6man-rfc6874bis-05: 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/groups/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-rfc6874bis/
> >>>
> >>>
> >>>
> >>> ----------------------------------------------------------------------
> >>> DISCUSS:
> >>> ----------------------------------------------------------------------
> >>>
> >>> Hi,
> >>>
> >>> I'm balloting discuss on this document because the encoding seems to
> >> exclude a
> >>> large number of common port/interface name representation across many
> >>> networking vendors that were allowed/supported by the previous RFC. I
> think
> >>> that it would be helpful to have a solution that accommodated these
> interface
> >>> names, or to understand why they don't need to supported.
> >>>
> >>> Specifically, the text in the introduction states:
> >>>
> >>> Zone identifiers are especially useful in contexts in
> >>> which literal addresses are typically used, for example, during
> fault
> >>> diagnosis, when it may be essential to specify which interface is
> >>> used for sending to a link-local address.
> >>>
> >>> and
> >>>
> >>> The mapping between the human-readable zone identifier string and
> the
> >>> numeric value is a host-specific function that varies between
> >>> operating systems. The present document is concerned only with
> the
> >>> human-readable string.
> >>>
> >>> But unlike RFC 6874, which stated:
> >>>
> >>> If an operating system uses any other characters in zone or
> interface
> >>> identifiers that are not in the "unreserved" character set, they
> MUST
> >>> be represented using percent encoding [RFC3986].
> >>>
> >>> The bis version of this document instead states:
> >>>
> >>> A zone identifier MUST contain only ASCII characters classified as
> >>> "unreserved" for use in URIs [RFC3986]. This excludes characters
> >>> such as "]" or even "%" that would complicate parsing.
> >>>
> >>> ...
> >>>
> >>> If an operating system uses any other characters in zone or
> interface
> >>> identifiers that are not in the "unreserved" character set, they
> >>> cannot be used in a URI.
> >>>
> >>> Many (or even most) network devices across multiple vendors use
> interface
> >> names
> >>> that all use characters that are not in the "unreserved" character set
> >>> (specifically, '/' is a very common separator for
> linecards/ports/sub-ports/etc
> >>> ...), and hence they would not be able to use the interface name (the
> obvious
> >>> zone identifier) as part of this new encoding.
> >>>
> >>> One could argue that the SNMP If-index or other internal numeric
> >> representation
> >>> of the zone identifier (i.e., really an interface name) could be used
> instead,
> >>> but the modern management APIs all use interface names (which in YANG
> >> allow for
> >>> a large subset of unicode characters) rather than numerical indexes to
> >> identify
> >>> interfaces. I also think that we want to get away from numeric ids as
> zone
> >>> identifiers in user facing uses.
> >>>
> >>> Regards,
> >>> Rob
> >>>
> >>>
> >>>
> >>>
> >>>
>
[Attachment #5 (text/html)]
<div dir="ltr">Rob,<div><br></div><div>I concur with Brian \
here.</div><div><br></div><div>Perhaps one source of difficulty here is that the zone \
id is logically internal to a node and is never externally observable (I can't \
think of any field in any transmitted datagram where it \
appears).</div><div><br></div><div>If your node displays different interface indexes \
for SNMP vs YANG vs CLI then some, or even none, of those are usable by any RFC \
{3493, 3542} style API (IPv6 BSD Sockets API). If your node has no such API for \
"apps" on the node to use then I suppose it doesn't have to worry about \
consistent scope identifiers.</div><div><br></div><div>-ek</div></div><br><div \
class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Jun 20, 2023 at \
2:49 PM Brian E Carpenter <<a \
href="mailto:brian.e.carpenter@gmail.com">brian.e.carpenter@gmail.com</a>> \
wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px \
0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi Rob,<br> <br>
On 21-Jun-23 03:54, Rob Wilton (rwilton) wrote:<br>
> Hi Brian,<br>
> <br>
> I don't regard interfaces on network devices as inherently having a numeric \
identifier.<br> <br>
But that *is* the model described in RFC 4007. If there are devices whose o/s \
doesn't support the model of a Zone ID plus a numeric index, then they are \
basically out of scope for this draft. Would it help if we added a clear statement to \
that effect?<br> <br>
> Many devices currently expose interfaces via the SNMP IfMib, and hence they \
assign and expose an IfIndex associated with the interface, but that identifier \
logically only exists/belongs to the SNMP management domain. E.g., a different \
management protocol could easily use a different format for interface identifiers, \
and e.g., in the case of YANG and CLI, they do.<br> <br>
I'm a bit surprised, but I believe that is orthogonal to the current draft, which \
does really rely on the identifier and index described in RFC 4007 as part of the \
IPv6 addressing model. From the comments made by Jürgen Schönwälder, it seemed \
that the index in management data models was identical to the index in the RFC 4007 \
model, but that the difficulties arose in the names. Doesn't the -08 draft make \
that clear and show how to avoid the issue by using the numeric index?<br> <br>
> <br>
> But I wonder if the issue that I have here, is that there should just be a more \
cleanly specified definition of what a zone-id is and what it is not. I.e., I think \
that a zone-id for an interface is a device unique arbitrary string that conforms to \
the ABNF in your draft. It could be an interface name, or a translated interface \
name, or a numeric id (that ideally would match the Ifindex if possible).<br> <br>
That's undoubtedly true, but fixing it is a major piece of work. Our goal here is \
to allow browsers and HTTP servers to handle what is currently implemented for the \
common operating systems, to meet increasingly urgent needs. Can we not proceed now \
by making it clear that this issue is out of scope?<br> <br>
> Hence, I wonder whether it wouldn't be cleaner for this document to formally \
update RFC 4007 to redefine what a zone-id is:<br> > - redefine the allowed \
character set for zone-ids (section 11.2), restricting it to the allowed URI \
character set.<br> > - indicate that it is RECOMMENDED for interfaces names \
be used directly as the zone-id for interface zones, if the interface name directly \
conform to the URI character set.<br> > - for interface names don't conform \
then (e.g., for most network devices) :<br> > - a device unique translated \
form of the interface name SHOULD be used that conforms to the zone-id character set \
(e.g., perhaps convert GigabitEthernet1/0/0/0.1 to ethernet1-0-0-0.1)<br> > \
- a device unique numeric identifier for the interface MAY be used as the zone-id \
instead of an end-user meaningful string. If the device supports the SNMP IfMIB, \
and a numeric zone identifier is desired, then the numeric identifier SHOULD match \
the IfMIB Ifindex for the interface.<br> > - the interface zone-id should be \
explicitly displayed in network management models and APIs in cases where it is \
helpful to support management operations (i.e., to solve your copy and paste \
requirement).<br> > <br>
> Is something like this a plausible way forward?<br>
<br>
Personal opinion: Yes, RFC 4007 needs significant revision. No, this draft is not the \
place to do it - it would be a long discussion. I think that it would be at least a \
year before anything stable comes out of 6MAN that also meets the needs of network \
management data models. Meanwhile, anyone who needs to use a complete link-local \
address in a browser is stuck.<br> <br>
Regards<br>
Brian<br>
<br>
> <br>
> Regards,<br>
> Rob<br>
> <br>
> <br>
>> -----Original Message-----<br>
>> From: Brian E Carpenter <<a href="mailto:brian.e.carpenter@gmail.com" \
target="_blank">brian.e.carpenter@gmail.com</a>><br> >> Sent: 20 June 2023 \
00:59<br> >> To: Rob Wilton (rwilton) <<a href="mailto:rwilton@cisco.com" \
target="_blank">rwilton@cisco.com</a>>; The IESG <<a \
href="mailto:iesg@ietf.org" target="_blank">iesg@ietf.org</a>><br> >> Cc: <a \
href="mailto:draft-ietf-6man-rfc6874bis@ietf.org" \
target="_blank">draft-ietf-6man-rfc6874bis@ietf.org</a>; <a \
href="mailto:6man-chairs@ietf.org" target="_blank">6man-chairs@ietf.org</a>; <a \
href="mailto:ipv6@ietf.org" target="_blank">ipv6@ietf.org</a><br> >> Subject: \
Re: Robert Wilton's Discuss on draft-ietf-6man-rfc6874bis-05: (with<br> >> \
DISCUSS)<br> >><br>
>> Rob,<br>
>><br>
>> I'm replying to your original DISCUSS for simplicity. We are now at \
version 08<br> >> of the draft, and waiting for the next step from the \
IESG.<br> >><br>
>> In summary, the changes since the IESG review are:<br>
>><br>
>> - Added NMEA use case.<br>
>> - Clearly explained cut-and-paste requirement.<br>
>> - * Clarified character set restrictions and the applicability of \
numeric<br> >> identifiers as a work-around.<br>
>> - * Updated ABNF to require lower case (due to host component case<br>
>> normalization)<br>
>> - Mentioned .local as another case of locally significant URIs.<br>
>> - Expanded text on handling of zone ID at server.<br>
>> - Added discussion of CORS.<br>
>> - Noted parsing fragility re % sign.<br>
>> - Noted potential exposure of MAC addresses in zone IDs<br>
>><br>
>> The changes marked with an asterisk are particularly relevant to your \
DISCUSS.<br> >> Unfortunately the general rules about URIs make it impossible \
to be case-<br> >> sensitive or to use certain symbols.<br>
>> (Operating systems such as Linux introduce their own restrictions, too.) \
To<br> >> resolve this, it is necessary to use numeric interface indexes \
instead of "human-<br> >> readable" names for those cases. That \
really is the best we can do.<br> >><br>
>> We look forward to your comments.<br>
>><br>
>> Regards<br>
>> Brian Carpenter + co-authors<br>
>><br>
>> On 16-Mar-23 11:44, Robert Wilton via Datatracker wrote:<br>
>>> Robert Wilton has entered the following ballot position for<br>
>>> draft-ietf-6man-rfc6874bis-05: Discuss<br>
>>><br>
>>> When responding, please keep the subject line intact and reply to \
all<br> >>> email addresses included in the To and CC lines. (Feel free to \
cut this<br> >>> introductory paragraph, however.)<br>
>>><br>
>>><br>
>>> Please refer to <a \
href="https://www.ietf.org/about/groups/iesg/statements/handling-" rel="noreferrer" \
target="_blank">https://www.ietf.org/about/groups/iesg/statements/handling-</a><br> \
>> ballot-positions/<br> >>> for more information about how to handle \
DISCUSS and COMMENT positions.<br> >>><br>
>>><br>
>>> The document, along with other ballot positions, can be found here:<br>
>>> <a href="https://datatracker.ietf.org/doc/draft-ietf-6man-rfc6874bis/" \
rel="noreferrer" target="_blank">https://datatracker.ietf.org/doc/draft-ietf-6man-rfc6874bis/</a><br>
>>><br>
>>><br>
>>><br>
>>> ----------------------------------------------------------------------<br>
>>> DISCUSS:<br>
>>> ----------------------------------------------------------------------<br>
>>><br>
>>> Hi,<br>
>>><br>
>>> I'm balloting discuss on this document because the encoding seems \
to<br> >> exclude a<br>
>>> large number of common port/interface name representation across \
many<br> >>> networking vendors that were allowed/supported by the previous \
RFC. I think<br> >>> that it would be helpful to have a solution that \
accommodated these interface<br> >>> names, or to understand why they \
don't need to supported.<br> >>><br>
>>> Specifically, the text in the introduction states:<br>
>>><br>
>>> Zone identifiers are especially useful in contexts in<br>
>>> which literal addresses are typically used, for example, during \
fault<br> >>> diagnosis, when it may be essential to specify which \
interface is<br> >>> used for sending to a link-local address.<br>
>>><br>
>>> and<br>
>>><br>
>>> The mapping between the human-readable zone identifier string \
and the<br> >>> numeric value is a host-specific function that \
varies between<br> >>> operating systems. The present document is \
concerned only with the<br> >>> human-readable string.<br>
>>><br>
>>> But unlike RFC 6874, which stated:<br>
>>><br>
>>> If an operating system uses any other characters in zone or \
interface<br> >>> identifiers that are not in the \
"unreserved" character set, they MUST<br> >>> be \
represented using percent encoding [RFC3986].<br> >>><br>
>>> The bis version of this document instead states:<br>
>>><br>
>>> A zone identifier MUST contain only ASCII characters classified \
as<br> >>> "unreserved" for use in URIs [RFC3986]. This \
excludes characters<br> >>> such as "]" or even \
"%" that would complicate parsing.<br> >>><br>
>>> ...<br>
>>><br>
>>> If an operating system uses any other characters in zone or \
interface<br> >>> identifiers that are not in the \
"unreserved" character set, they<br> >>> cannot be used in \
a URI.<br> >>><br>
>>> Many (or even most) network devices across multiple vendors use \
interface<br> >> names<br>
>>> that all use characters that are not in the "unreserved" \
character set<br> >>> (specifically, '/' is a very common separator \
for linecards/ports/sub-ports/etc<br> >>> ...), and hence they would not be \
able to use the interface name (the obvious<br> >>> zone identifier) as part \
of this new encoding.<br> >>><br>
>>> One could argue that the SNMP If-index or other internal numeric<br>
>> representation<br>
>>> of the zone identifier (i.e., really an interface name) could be used \
instead,<br> >>> but the modern management APIs all use interface names \
(which in YANG<br> >> allow for<br>
>>> a large subset of unicode characters) rather than numerical indexes \
to<br> >> identify<br>
>>> interfaces. I also think that we want to get away from numeric ids as \
zone<br> >>> identifiers in user facing uses.<br>
>>><br>
>>> Regards,<br>
>>> Rob<br>
>>><br>
>>><br>
>>><br>
>>><br>
>>><br>
</blockquote></div>
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic