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

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

Correction: it's only disclosure 5688 that is unavailable. I reported it.

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