Hi Brian,
The restructuring of discovery work into
a) minimum MTI mechanism in the individual BRSKI variation drafts
b) brski-discovery draft for the generic discovery solution
was especially made to avoid delaying RFC release of the BRSKI variations with
the
generic discovery solution, so from that goal i would like to argue against what
you are asking for.
however: If we happen to progress brski-discovery roughly as quickly as (some
of)
the BRSKI drafts, and they end up being in the RFC editor queue at the same
time,
MichaelR told me that even those informative reference would be upgrade to the
RFC number, sometimes even assigning the RFC numbers before those RFC are
officially
released. And maybe one could force this by asking those RFC to be cluseted to
achieve this.
Cheers
Toerless
On Sat, Aug 17, 2024 at 08:24:14AM +1200, Brian E Carpenter wrote:
> One more comment in line:
>
> On 16-Aug-24 18:05, Fries, Steffen wrote:
> > Hi Brian,
> >
> > Thank you for your two proposals.
> >
> > > -----Original Message-----
> > > From: Brian E Carpenter <[email protected]>
> > > Sent: Wednesday, August 14, 2024 11:07 PM
> > > Hi,
> > >
> > > I am mainly OK with this draft, but I see two sentences that bother me:
> > >
> > > At the end of section 6.1.1:
> > >
> > > > > Defining discovery extensions is out of scope of this document.
> > > > > This may be
> > > provided in [I-D.ietf-anima-brski-discovery].
> > >
> > >
> > > At the beginning of section 6.1.2:
> > >
> > > > > A more general discovery mechanism, also supporting GRASP besides
> > > > > DNS-
> > > SD with mDNS, may be provided in [I-D.ietf-anima-brski-discovery].
> > >
> > > I don't understand the words "may be provided". The reference is listed as
> > > Informative, but it isn't clear to me what "may" means, since it is an
> > > ambiguous
> > > word in English. Does it mean that the authors of brski-discovery haven't
> > > decided
> > > yet, that the mechanisms defined in brski-discovery are OPTIONAL, or
> > > something
> > > else?
> >
> > [stf] We included the reference to BRSKI-discovery at a very early point of
> > discussing the new draft. Therefore we wrote "may". But you are correct
> > with the proposals you made below, it does not sound vague so I would
> > simply take your proposals over in BRSKI-PRM. I added this for traceability
> > as issue #134
> >
> > >
> > > Possibly these two rewrites are what the authors intended to say:
> > >
> > > Defining discovery extensions is out of scope of this document. For
> > > further
> > > discussion, see [I-D.ietf-anima-brski-discovery].
> > >
> > > A more general discovery mechanism, also supporting GRASP besides DNS-SD
> > > with mDNS, is discussed in [I-D.ietf-anima-brski-discovery].
> > >
> > > I also wonder whether the Informative reference is correct, since
> > > brski-discovery is
> > > also standards track. Do we really want brski-prm to be published with the
> > > reference pointing to an I-D rather than to an RFC?
> >
> > [stf] Regarding BRSKI-discovery being an informative reference, BRSKI-PRM
> > does not depend on the functionality defined in BRSKI-discovery, as it
> > utilizes the mDNS approach already applied in BRSKI. BRSKI-discovery
> > enhances the capability detection of registrars and thus improves detecting
> > the registrar matching the pledges functionality instead of trial and
> > error. Therefore I would leave it as informative reference.
>
> I understand that. I still think it would be better for the reference to be a
> published RFC, which would mean asking the RFC Editor to wait. (This is an
> opinion, not a show-stopper.)
>
> Thanks,
> Brian
>
> >
> > Best regards
> > Steffen
> > >
> > > Regards
> > > Brian Carpenter
> > >
> > > On 14-Aug-24 20:10, Toerless Eckert wrote:
> > > > [resending, recipient list got messed up, sorry]
> > > >
> > > > Dear ANIMA-WG
> > > >
> > > > I am hereby want to do a lightweight last call to the WG before moving
> > > > draft-ietf-
> > > anima-brski-prm-14 to our AD, Mahesh.
> > > >
> > > > draft-ietf-anima-brski-prm-06 successfully finished WGLC in early 2023.
> > > > The editorial feedback from the WG lead to updates finished around
> > > > draft-ietf-
> > > anima-brski-prm-11.
> > > > Afterwards, Matthias Kovatsch did a very thorough shepherd review
> > > > whose editorial feedback was incorporated up to the curent version,
> > > > draft-ietf-
> > > anima-brski-prm-14.
> > > >
> > > > I am positive that all those who did provide feedback during WGLC did
> > > > check that their feedback was correctly addressed, i know mine and
> > > > Matthias (Shepherds) feedback has been addressed. Likewise, testing
> > > > with prototypes has successfully been done since WGLC.
> > > >
> > > > Neither WGLC feedback nor shepherd review did introduce any functional
> > > > changes to the protocol, but of course, the amount of restructuring
> > > > and and editorial improvements to the text is substantial, and this is
> > > > why Mahesh
> > > asked us at IETF120 to check before taking over.
> > > >
> > > > Therefore i would like to give the WG a last opportunity to raise
> > > > issues.
> > > > If no substantial issues are raised, i will pass on the draft to our AD
> > > > on
> > > 08/23/2024 (end of next week).
> > > >
> > > > Thank you so much to everybody who helped to create this work!
> > > >
> > > > Toerless - for the chairs.
> > > >
> > > > On Mon, Feb 20, 2023 at 04:20:05PM +0000, Fries, Steffen wrote:
> > > > > Hi Sheng,
> > > > >
> > > > > I will provide an updated version by tomorrow, incorporating the
> > > > > proposed
> > > changes.
> > > > >
> > > > > Best regards
> > > > > Steffen
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: Sheng Jiang <[email protected]>
> > > > > > Sent: Montag, 20. Februar 2023 04:42
> > > > > > To: anima <[email protected]>; Toerless Eckert <[email protected]>;
> > > > > > anima-chairs <[email protected]>; draft-ietf-anima-brski-prm
> > > > > > <draft-ietf-anima-brski- [email protected]>; ietf <[email protected]>
> > > > > > Cc: ietf <[email protected]>
> > > > > > Subject: Re: WGLC for draft-ietf-anima-brski-prm-06, ends Feb. 15th,
> > > > > > 2023
> > > > > >
> > > > > > During the WGLC period, this drafts has received no objections, but
> > > comments.
> > > > > > Therefore, the chairs would draw on a passed conclusion . The WG
> > > > > > discussed the authors' suggestion that move the YANG components of
> > > > > > this to rfc8366bis and reach the consensus to respect the authors'
> > > > > > choice. The authors please submit an update version. Then, the
> > > > > > document
> > > shepherd can move it forward.
> > > > > >
> > > > > > Regards,
> > > > > >
> > > > > >
> > > > > > --------------
> > > > > >
> > > > > >
> > > > > >
> > > > > > Sheng Jiang
> > > > > >
> > > > > >
> > > > > >
> > > > > > > Dear ANIMAers,
> > > > > >
> > > > > >
> > > > > >
> > > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > > This message starts the two-week (*) ANIMA Working Group Last Call
> > > > > > > to
> > > > > > advance draft-ietf-anima-brski-prm-06, which specifies enhancements
> > > > > > to BRSKI
> > > > > > (RFC8995) to facilitate bootstrapping in domains featuring no or
> > > > > > only time limited connectivity between a pledge and the domain
> > > > > > registrar. This document's intended status is Standards Track. At
> > > > > > present, there is no IPR filed against this document. This document
> > > > > > has been ANIMA WG document since October, 2021 and has received a
> > > > > > lot of feedback from the WG and work from its authors. The authors
> > > > > > therefore think is ready for WGLC. Please send your comments by Feb.
> > > > > > 15th 2023. If you do not feel this document should advance, please
> > > > > > state your reasons why. Matthias Kovatsch is the assgined
> > > document shepherd.
> > > > > >
> > > > > >
> > > > > >
> > > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > > Regards,
> > > > > >
> > > > > >
> > > > > >
> > > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > > Sheng
> > > > > >
> > > >
> > > > _______________________________________________
> > > > Anima mailing list -- [email protected]
> > > > To unsubscribe send an email to [email protected]
>
--
---
[email protected]
_______________________________________________
Anima mailing list -- [email protected]
To unsubscribe send an email to [email protected]
