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

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

> Ten IPR claims  - 5688 to 5697 - were submitted last week

These disclosures are not available to the public.

> What should happen when IPR claims are submitted against the RFC Editor
> Queue?

I believe the document(s) must be put on hold and referred back to the WG,
although as Scott Bradner pointed out, such a late disclosure would be viewed
very negatively by the courts.

Regards
    Brian Carpenter

On 27-Jun-22 23:04, tom petch wrote:
> On 24/06/2022 17: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?
> 
> Ten IPR claims  - 5688 to 5697 - were submitted last week against I2NSF
> documents, most of which have now reached the RFC Editor Queue
> (MISSREF), one unadopted (draft-lingga-i2nsf-application-interface-dm).
>    All specify 'Possible Royalty Fee'.  The name of the patent holder
> would appear to be the name that has figured most prominently in the
> progress of these I-D as author and the one who posts responses to
> comments, usually in the form of PDF.  All except the one relating to
> the unadopted I-D would appear to relate to versions that appeared some
> time ago, 2019, 2020. (I find the format of the IPR claim not easy to
> follow and here, parts are in CJK script which I do not understand).
> 
> Five similar claims - 3553 to 3557 - were filed in June 2019 around the
> time of WGLC for one of the I-D.  Posts at that time are clear that
> 'Possible Royalty/Fee' would not be acceptable to the WG and that the
> I-D should not progress.  Revised claims - 3603 to 3607 - were submitted
> with different licensing, the often used reciprocity clause, and the WG
> deemed those acceptable for the work to continue.
> 
> Some of the claims specify the sections of the I-D and at least one
> (5695) appears to include the 'IANA Considerations' in that.  This
> interests me as these are for YANG modules and the original choice of
> YANG prefix seemed unhelpful.  One of my contributions was to propose
> revised YANG prefix for all the modules along the lines used in other WG
> and my suggestions were adopted (albeit after the revision for which the
> IPR is claimed - I make no IPR claim for this idea:-)
> 
> So very late IPR claims, seemingly for revisions from some time ago,
> with licensing that the WG had already found unacceptable relating to a
> patent that would appear to be for one of the authors.
> 
> What should happen when IPR claims are submitted against the RFC Editor
> Queue?
> 
> Tom Petch
> 
> 
>>      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
>>>>>>>
>>
> 
> _______________________________________________
> Ipr-wg mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ipr-wg