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]
_______________________________________________
Anima mailing list -- [email protected]
To unsubscribe send an email to [email protected]
