Re: I-D Action: draft-ietf-6man-rfc6874bis-01.txt - YANG

[Brian E Carpenter <[e-mail]>]

Hi Tom,

> Certainly reviewers of YANG modules, such as YANG doctors, know well that when it is pointed out to the author that 'ip-address' allows for a zone, then most, but not all, authors switch to the no-zone type.

That really sounds like storing up trouble, unless there is some absolute assurance that the relevant YANG usage will never, ever, apply to a host with more than one IPv6 interface that may need to be addressed with a link local address. A link local address without a zone is simply incomplete (and the notion of a default zone is not universally supported even when there is only one interface).

However, I don't believe we need to address this issue in 6874bis, do we?

Regards
    Brian

On 09-Apr-22 23:34, tom petch wrote:
> Top posting and tweaking the subject slightly for a different slant on zone ...
> 
> The YANG data modelling language defines types - int, string, ... - and allows derived types based on them which RFC6021 does to define such as gauge, counter, URI .. and ip-address.  This last was defined as a string with a regex that allowed for an optional zone.  This was seen as too limiting so rfc6021bis, i.e. RFC6991, added variants such as ip-address-no-zone.
> 
> Now an rfc6991bis has passed WG LC and was about to go forward when the comment was made that the identifier 'ip-address' misleads authors, who take it as literal, and should be redefined to exclude the optional zone. Certainly reviewers of YANG modules, such as YANG doctors, know well that when it is pointed out to the author that 'ip-address' allows for a zone, then most, but not all, authors switch to the no-zone type.
> 
> Such a change breaks the backwards compatibility rules of RFC7950 and will break any YANG module whose author has read the documentation and has used 'ip-address' because
> the zone is required.  Such modules exist.
> 
> By contrast, I have seen no reference to the existing formulation causing problems.  It could, with a server or client inserting a zone which the client or server does not expect and cannot interwork with.   Such a failure is, at present, hypothetical.
> 
> The discussion on this started on the LSR WG list and is now also on the NETMOD WG list with a Subject:  of Re: I-D Action: draft-ietf-lsr-ospfv3-extended-lsa-yang-10.txt.  The AD has indicated that he thinks the change should be made.
> 
> Isn't it fun how after all these decades IPv6 can still generate discussion on such issues?
> 
> Tom Petch
>   
> From: ipv6 <[e-mail]> on behalf of Brian E Carpenter <[e-mail]>
> Sent: 08 April 2022 03:29
> To: [e-mail]
> Subject: Re: I-D Action: draft-ietf-6man-rfc6874bis-01.txt
> 
> Hi,
> 
> This version reflects comments at the IETF and on the list.
> Change log:
> * Extended use cases (added Microsoft WSD)
> * Clarified relationship with RFC3986 language
> * Allow for legacy use of RFC6874 format
> * Augmented security considerations
> * Editorial and reference improvements
> 
> Note that some of the text about RFC3986 that Shang Ye
> suggested to remove has been retained, but modified. Further
> comments about this, or any other aspect, are very welcome.
> 
> Regards
>      Brian + co-authors
> 
> On 08-Apr-22 14:13, [e-mail] wrote:
>>
>> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>> This draft is a work item of the IPv6 Maintenance WG of the IETF.
>>
>>           Title           : Representing IPv6 Zone Identifiers in Address Literals and Uniform Resource Identifiers
>>           Authors         : Brian Carpenter
>>                             Stuart Cheshire
>>                             Robert M. Hinden
>>        Filename        : draft-ietf-6man-rfc6874bis-01.txt
>>        Pages           : 13
>>        Date            : 2022-04-07
>>
>> Abstract:
>>      This document describes how the zone identifier of an IPv6 scoped
>>      address, defined as <zone_id> in the IPv6 Scoped Address Architecture
>>      (RFC 4007), can be represented in a literal IPv6 address and in a
>>      Uniform Resource Identifier that includes such a literal address.  It
>>      updates the URI Generic Syntax and Internationalized Resource
>>      Identifier specifications (RFC 3986, RFC 3987) accordingly, and
>>      obsoletes RFC 6874.
>>
>>
>> The IETF datatracker status page for this draft is:
>> https://datatracker.ietf.org/doc/draft-ietf-6man-rfc6874bis/
>>
>> There is also an HTML version available at:
>> https://www.ietf.org/archive/id/draft-ietf-6man-rfc6874bis-01.html
>>
>> A diff from the previous version is available at:
>> https://www.ietf.org/rfcdiff?url2=draft-ietf-6man-rfc6874bis-01
>>
>>
>> Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts
>>
>>
>> _______________________________________________
>> I-D-Announce mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/i-d-announce
>> Internet-Draft directories: http://www.ietf.org/shadow.html
>> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>>
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>