Re: FWD: Assertion of an issue with previously undisclosed IPR involving YANG and maybe draft-ietf-core-problem-details

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

If I have it right, the -00 version of the individual draft that led to the approved draft is dated 2016-10-31, and at least one of the patent applications involved is dated 2019-06-12. I'm no lawyer, but there may be prior art here anyway.

That said, further disclosures after the document is fully approved seem very strange, to say the least. It may be worth somebody involved glancing at RFC6701.

Regards
    Brian Carpenter

On 25-Jun-22 04:33, John C Klensin wrote:
> Hi.  As if people didn't have enough to worry about...
> 
> Assuming Tom's description is correct and I understand it
> correctly, the note below involves an author/Contributor who was
> presumably completely aware of the disclosure rules (not just
> from the Note Well and documents it references but from earlier
> experience) but who nonetheless chose to defer making a claim
> about an encumbrance and possible royalties until very late in
> the process.  Is it time for (another) discussion about how we
> might prevent or mitigate such behavior?  Should we, when
> publishing such disclosures, have a mechanism to attach a
> timeline that might assist someone evaluating the claim or
> considering a challenge to it?
> 
>     best,
>      john
> 
> 
> 
> 
> ---------- Forwarded Message ----------
> Date: Friday, June 24, 2022 17:01 +0100
> From: tom petch <[e-mail]>
> To: "Martin J. Dürst" <[e-mail]>, Ira McDonald
> <[e-mail]>
> Cc: Carsten Bormann <[e-mail]>, Harald Alvestrand
> <[e-mail]>, Applications and Real-Time Area
> Discussion <[e-mail]>, Core WG mailing list <[e-mail]>,
> [e-mail], [e-mail]
> Subject: Re: [Last-Call] [art] Artart last call review of
> draft-ietf-core-problem-details-05 YANG
> 
> Slight tweak to the subject line for this narrow focus on YANG
> 
> On 24/06/2022 13:28, Martin J. Dürst wrote:
>> Hello Tom, others,
>>
>> Thanks for bringing the Yang issues, in particular the
>> leaf_language definition, to our attention. That leaf_language
>> regular expression is complete overkill; the same arguments
>> that I gave to Carsten re. his copied ABNF apply.
>>
>> It may be too late to fix
>> draft-ietf-i2nsf-nsf-facing-interface-dm, but if there's still
>> a chance, that would be great. If it's too late for
>> draft-ietf-i2nsf-nsf-facing-interface-dm, I hope it's not too
>> late for some other YANG drafts.
>>
>> I'm glad that Francesca is pushing for language information
>> where it matters, but we should make sure that this doesn't
>> end up in copying needlessly complicate regular expressions.
> 
> The I2NSF I-D is with the RFC Editor MISSREF as is
> nsf-monitoring. -capability has not got language tags while
> -consumer-facing has and is still a WG document.  IPR claims
> were submitted this week against all the I-D with 'Possible
> Royalty Fee'.  Similar claims were submitted three or four years
> ago and the inclusion of the Fee led to resistance about the
> work being done whereupon the Licensing was changed to be
> acceptable.  The referenced document in the IPR claim is from
> 2019. The referenced sections are the YANG module and the
> examples and in some cases the IANA Considerations.  The
> inventor of the unpublished patent appears to be the same as the
> IETF partipant who has been driving and authored much of the
> I2NSF work.  Nothing to do with language tags except that if the
> claim is applied to the more recent I-D then it could cover the
> regular expression.  Having been involved with the I2NSF I-D for
> some years, I am no longer surprised by such happenings.
> 
> Tom Petch
> 
> 
> 
> 
> 
> 
> 
> 
> 
>>
>> Regards,    Martin.
>>
>> On 2022-06-24 19:44, tom petch wrote:
>>> Just on the YANG point
>>>
>>> On 24/06/2022 11:20, Ira McDonald wrote:
>>>> Hi,
>>>>
>>>> Hmm...I knew I should have been silent in this thread...
>>>>
>>>> John - you're right that any future update to RFC 5646 will
>>>> be carefully backwards compatible.
>>>> And Martin could answer (off list) your question about
>>>> possible future changes.
>>>>
>>>> Tom - many copies in YANG or anywhere else is a disturbing
>>>> idea.  Any computer language
>>>> that doesn't have a good mechanism for namespaces, import,
>>>> and export isn't
>>>> fully baked.
>>>> And I know so little about YANG that I don't even know what
>>>> it can do here.
>>>
>>> Ira,
>>>
>>> YANG does have import but it is a bit clunky.  The I2NSF have
>>> a cluster of six closely related modules which cries out for
>>> a common module but the WG chose not to use that approach so
>>> there is much replication, much ovelap in their modules e.g.
>>> with language tags.
>>>
>>> The NETMOD WG produced RFC6991 which provided common types
>>> and is used by almost all YANG modules and 6991bis has just
>>> completed WGLC so that is the natural place to put a language
>>> type.  6991 works because it was based on decades of
>>> experience with SMI but other WG are not so skilled at
>>> judging when to create a common module and what to put in it.
>>> The opsawg WG is an interesting case study therein.
>>>
>>> So with Francesca raising this issue several times I have
>>> asked NETMOD to include a language tag construction in
>>> 6991bis but since the I-D has a long history and is much
>>> overdue, then I expect that they will be reluctant to act,
>>> but I have asked.
>>>
>>> Tom Petch
>>>
>>>
>>>> CORE - please delete *all* of your CDDL details for language
>>>> tags and just
>>>> use one of the
>>>> several excellent libraries that correctly parse language
>>>> tags, when needed.
>>>>
>>>> All - one of the  key ethical reasons for the Internet is
>>>> fair access to information for all.  The
>>>> correct use of language tags is really important.  The idea
>>>> of inferring human language from
>>>> the context is nonsense, because the upper layer context is
>>>> often the first
>>>> thing discarded.
>>>>
>>>> I will now leave it to Francesca to keep bothering the IESG
>>>> about language
>>>> tags and return
>>>> to my cave and worry about automotive security.
>>>>
>>>> Cheers,
>>>> - Ira
>>>>
>>>>
>>>> *Ira McDonald (Musician / Software Architect)*
>>>>
>>>> *Chair - SAE Trust Anchors and Authentication TF*
>>>> *Co-Chair - TCG Trusted Mobility Solutions WG*
>>>>
>>>> *Co-Chair - TCG Metadata Access Protocol SG*
>>>>
>>>>
>>>> On Fri, Jun 24, 2022 at 4:54 AM tom petch
>>>> <[e-mail]> wrote:
>>>>
>>>>> On 23/06/2022 22:08, Ira McDonald wrote:
>>>>>> Hi Carsten,
>>>>>>
>>>>>> I take your point about copying from a given RFC.
>>>>>>
>>>>>> But the history of IETF Language Tags is RFC 1766 (1995),
>>>>>> RFC 3066
>>>>> (2001),
>>>>>> RFC 4646 (2006), and RFC 5646 (2009).  It's a long time
>>>>>> since 2009 and,
>>>>> as
>>>>>> Martin noted, there have been a variety of proposals for
>>>>>> updating
>>>>> language
>>>>>> tags in the past 13 years, so it's reasonably likely that
>>>>>> there will be a
>>>>>> newer
>>>>>> version at some point.  And since language tags are now
>>>>>> quite structured,
>>>>>> the chance of not needing syntax changes is fairly low.
>>>>>> This draft RFC
>>>>> from
>>>>>> CORE wouldn't catch up quickly, presumably.
>>>>>
>>>>> Probably a left field comment.
>>>>>
>>>>> I had not heard of, or forgotten about, language tags until
>>>>> the IESG review of draft-ietf-i2nsf-nsf-facing-interface-dm
>>>>> drew a DISCUSS from Francesca because the 26 YANG string
>>>>> that were meant to be human readible had no language tags.
>>>>> She pointed to RFC2277 while saying that
>>>>> RFC5646 should be a Normative Reference.
>>>>>
>>>>> The I-D was revised to include a YANG leaf 'language' with
>>>>> a horrendous YANG pattern spanning 25 lines.
>>>>>
>>>>> Two consequences.  The pattern, doubtless a gross
>>>>> simplification of what
>>>>> it might have been, was wrong and was revised - I have not
>>>>> looked to see
>>>>> if it makes sense now but then I did not spot the error in
>>>>> the first place - so I have the sense that, like trying to
>>>>> specify a pattern for IPv6 address, language tags are easy
>>>>> to get wrong.  Second there is now a pattern of Francesca
>>>>> throwing DISCUSS at other similar I-D so language
>>>>> tags, and their modelling in YANG, could get more attention
>>>>> (at least while Francesca is on the IESG:-) her comments
>>>>> could have been made about any number of earlier YANG RFC).
>>>>> The pattern in the I2NSF I-D cannot be imported into
>>>>> another YANG module, rather each YANG module that draws a
>>>>> DISCUSS will contain a fresh copy.  If ideas evolve, then
>>>>> there are likely to be many disparate copies.
>>>>>
>>>>> Tom Petch
>>>>>
>>>>>>
>>>>>> Cheers,
>>>>>> - Ira
>>>>>>
>