Apologies — I think I dropped the ball on getting back to you about this one. 
The PR looks good, modulo text about handling of other redirect codes.


________________________________
From: Michael Richardson
Sent: Wednesday, August 6, 2025 5:41 PM
To: Mike Bishop
Cc: The IESG; draft-ietf-anima-brski-cl...@ietf.org; anima-cha...@ietf.org; 
anima@ietf.org; shengji...@bupt.edu.cn
Subject: Re: [Anima] Mike Bishop's Discuss on draft-ietf-anima-brski-clou d-16: 
(with DISCUSS and COMMENT)


this week's changes are at:
     https://github.com/anima-wg/brski-cloud/pull/248/files

The previous PR got merged too soon.

Mike Bishop <mbis...@evequefou.be> wrote:
    > Okay. Didn't know about that document.
    > Is this what you had in mind:
    > 
https://github.com/anima-wg/brski-cloud/pull/247/commits/3e721e8ce55226a3a97cfadfba04d0670a62b11f

    > [MB] I don't know that you need a section reference every time you
    > mention a status code, though you certainly can. I was thinking more of
    > the places you say "as defined by [BRSKI] and HTTP" but HTTP isn't a
    > reference to 9110. Turning that into [HTTP] would make sense.

I've done exactly this now.

[MB] There are a few other references to HTTP where adding the pointer might be 
reasonable, but that's an editorial consideration — I'm fine to clear the 
DISCUSS so long as it's a normative reference of the document.

    > I don't know what you mean here.
    > I think that "Link relation" involves RDF or HTML stuff, and we are not 
using either.

    > [MB] Link relations are defined in RFC8288, and allow an HTTP header to
    > describe the relationship of other resources to the one being
    > accessed. However, if the redirect payload is the same, redirects will
    > work.

I read through 8288.
I see that we can use this Link: header, and rather than the meta http-equiv
way that I'm more familiar with.
I looked through 
https://www.iana.org/assignments/link-relations/link-relations.xhtml
Nothing jumped out as an existing link type that we could use, that would be
somehow more useful than 307.

[MB] That's fine — thanks for checking.

    > Any other 3xx that redirected to a different origin would have to be 
rejected outright.
    > 303 with Location: header seems similar to 201+Location: header, which we
    > explicitely allow in the Registrar<->MASA interaction in RFC8995.
    > I can add text explaining why the rest of 3xx are all probably wrong, but 
I'm
    > not sure about 303 yet.

    MB> Yes, it's similar, and a 201 is probably even more appropriate given
    MB> that the response will need to be unique to the request rather than
    MB> being an existing resource that satisfies the client's request. The
    MB> more general point is that just after the section of RFC 9205 you cite 
below, it says:

I'm used to 201+Location to refer to a *unique* place that should be polled
(GET,HEAD,If-*) to get the result.   But, at each step, Cloud Register X does
not know what the unique URL for Cloud Register X+1 would be.
307 seems the correct answer to me.  Go *THERE* and do a POST.

[MB] Using 307 for your expected flow is fine. You still need to specify what 
should happen with other status codes, since HTTP in general (intermediaries, 
etc.) might still encounter them in the wild.

    > -The details of the URI are Manufacturer specific, with BRSKI giving the 
example "brski-registrar.manufacturer.example.com".
    > -
    > -The Pledge SHOULD be provided with the entire URI of the Cloud 
Registrar, including the protocol and path components, which are typically 
"https://"; and "/.well-known/brski", respectively.
    > +The details of the URI are Manufacturer specific.
    > +For example, 
https://brski-registrar.manufacturer.example.com/.well-known/brski.

    MB> Okay, I see the definition in 8995. It's fine to parallel that
    MB> construction here — copying the language about assuming the scheme and
    MB> path components if they're omitted, for example. But saying it's
    MB> manufacturer-specific and leaving them to deal with it works, too.

In 8995, we allow the IDevID extension to be just the `authority` to be save
a dozen bytes.  But maybe in ten years, https will be all cringe.
The Registrar has to know this, so it's not a private matter.
But, in the Cloud-Registrar process, the manufacturer controls the first step
(Pledge->First Registrar), and then it's all supply-chain specific, and fully
specified by the 307 chain.

[MB] Works for me.

    > I think that we've tried to do this, and I think that we haven't tried to
    > jump on wrong codes, nor make a one-to-one relationship.   We have 
identified
    > some errors that map to specific codes (so many-to-one).
    > [PROBLEM-DETAILS] could be useful, but who would the pledge tell given 
that
    > it has no UI or user.   Not telling people not to use it.

    MB> Ah, so it's a matter of the requested identity/manufacturer not being
    MB> found on the server. That mapping makes sense with context, thanks.

Exactly.

    > {
    > Note that we avoided 418. We really wanted to :-)
    > Well, technically it would have been: "You are teapot"
    > }

    MB> Maybe the pledge could use it from its management interface. One
    MB> of the few areas of the IETF that could realistically specify a use for
    MB> 418!

NO SIR! I can also Brew expresso-sized Cappacinos!
(as the machines in Madrid seemed to be...)

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     m...@sandelman.ca  http://www.sandelman.ca/        |   ruby on rails    [


--
Michael Richardson <mcr+i...@sandelman.ca>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide




_______________________________________________
Anima mailing list -- anima@ietf.org
To unsubscribe send an email to anima-le...@ietf.org

Reply via email to