Hi Ranga,

The IETF doesn't have a good way to capture improvement suggestions such
as this.   Perhaps you could file an Errata suggesting a small tweak that would
improve the text a little.   Even if the errata is rejected, it will still live 
forever in
the tracker and undoubtedly reviewed if ever an update to the RFC is being
considered.

Kent // co-author



> On Feb 19, 2019, at 1:09 PM, M. Ranganathan <[email protected]> wrote:
> 
> 
> 
> On Tue, Feb 19, 2019 at 6:55 AM Toerless Eckert <[email protected] 
> <mailto:[email protected]>> wrote:
> Ranga,
> 
> It depends ;-)
> 
> Pledge P registers at a specific registrar B. B examines the audit log and
> determines that P was previously registered at another registrar A. Now
> B can see from theidentity of A in the audit log if A belongs to the
> same trust domain as B. If yes, then B would likely happily re-register
> P. Use-case: A failed and was replaced by B, or multiple registrars in
> the trust domain. Alternative, A is not known to be in the same trust
> domain by B, so B would refuse to register P, probably raise an
> exception to operations. In this case, i could come up with a range of
> use case examples what operations would do next.
> 
> Does this help ?
> 
> Cheers
>     Toerless
> 
> 
> HI Toerless,
> 
> Yes that clarifies things and in line with the mental picture I had built in 
> my mind. Perhaps it would be a good idea to clarify the document with an 
> explanation like you have stated above..
> 
> Thanks,
> 
> Ranga
> 
> 
> P.S.: Experimenting if the old alias for the co-authors still work. I
> think IETF tools keep it alife for a few years.
> 
> On Fri, Feb 08, 2019 at 02:21:57PM -0500, M. Ranganathan wrote:
> > Clarification on question below:
> > 
> > On Fri, Feb 8, 2019 at 11:22 AM M. Ranganathan <[email protected] 
> > <mailto:[email protected]>> wrote:
> > 
> > > Hello,
> > >
> > > I am reading the voucher artifact RFC 8366. I am confused about how the
> > > "audit voucher" (page 6) is supposed to be used. Specifically, the text
> > > says  " The registrar mitigates a MiTM registrar by auditing that an
> > > unknown MiTM registrar does not appear in the log entries. " How can it do
> > > this? Any concrete example that clarifies this use case would help me
> > > understand.
> > >
> > >
> > What is confusing me is the interpretation of the term "Man In The Middle"
> > (MiTM). Am I correct in assuming that this refers to previous registrars
> > where the device may have successfully registered?
> > 
> > 
> > > I am not sure if this is the correct mailing list for this question.
> > > Thanks in advance for your help.
> > >
> > > Regards,
> > >
> > > Ranga
> > >
> > > --
> > > M. Ranganathan
> > >
> > >
> > 
> > -- 
> > M. Ranganathan
> 
> > _______________________________________________
> > Anima mailing list
> > [email protected] <mailto:[email protected]>
> > https://www.ietf.org/mailman/listinfo/anima 
> > <https://www.ietf.org/mailman/listinfo/anima>
> 
> 
> -- 
> M. Ranganathan 
> 
> _______________________________________________
> Anima mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/anima

_______________________________________________
Anima mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/anima

Reply via email to