Yes, the discussions in both SPRING and 6man prove that there is a group of folks who either do not like and do not accept the existence of RFC 8986 or simply do not fully understand what it contains.
I do not think that as such it is sufficient not to accept the document as a WG draft observing the amount of industry support for it as expressed on the list. At min as requested a solid list of technical issues should have been provided where text in the draft goes above to what is already written in RFC8986. Kind regards, Robert. On Sun, Oct 31, 2021 at 7:47 PM Joel M. Halpern <j...@joelhalpern.com> wrote: > From my perspective the discussions as part of the adoption call in > SPRING, and the discussions in 6man make it clear that there is an issue > to be resolved. It may be that the issue will be resolved in saying > there is nothing that needs to be specified. It may be resolved by > saying that there are differences, and that they are acceptable. There > are many other ways that it may be resolved. > > It is my job as chair, given the policy, to determine that there is an > apparent discrepancy that needs to be addressed. I have done so. > > Yours, > Joel > > On 10/31/2021 2:31 PM, Robert Raszuk wrote: > > > > I am not attempting to revisit the question of whether RFC 8986 > > complies > > with RFC 4191. > > This compression documents raises additional issues beyond those in > > 8986 > > in some aspects of the flavors it describes. > > > > > > Could you be so kind and enumerate where in the draft you see *anything* > > crossing the line by defining new semantics for the ARG part of the SID > > as defined in RFC8986 ? > > > > Hint: your argument could have been sustainable if RFC8986 would put > > additional restrictions on the ARG field. But it does not. > > > > Many thx, > > Robert > > >
_______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
