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

[t petch <[e-mail]>]

On 28/06/2022 04:53, Brian E Carpenter wrote:
> Correction: it's only disclosure 5688 that is unavailable. I reported it.

Brian

My apologies, I got the numbers slightly wrong. I should have said
5689 to 5698
so 5688 should not have figured.  As you say, access is restricted.

5697 is the one that I think is about a current but unadopted I-D with 
an unpublished patent with a date of 2022-04-28 with a Possible 
Royalty/Fee (which the WG found unacceptable in june 2019).

Tom Petch

p.s.
I find that recent 'upgrade' to the datatracker now makes it difficult 
for me to find IPR Claims.  I can link from e-mail or type in the URL 
but not search.  Doubtless a move to push me onto an ugly browser:-(

>
> Regards
>     Brian Carpenter
>
> On 28-Jun-22 10:41, Brian E Carpenter wrote:
>>> 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
> _______________________________________________
> Ipr-wg mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ipr-wg