[email protected] writes:
> [Med] Yes, the initiator may include a suggested ALPN (protocol) for
> example to specifically indicate it is looking for DoT (or another
> protocol). The initiator may omit the ADN, but only include service
> parameters (typically, ALPN) to indicate a preferred transport
> protocol.

I was assuming there is some way of indicating that, but I could not
quickly find any examples of that, that is why I wanted to have more
examples in this draft, so I could see what values the alpn can have
:-) 

> 
> > 
> >   CP(CFG_REQUEST) =
> >      ENCDNS_IP6(23, 1, 16,
> >                 (2001:DB8:99:88:77:66:55:44),
> >                     "doh1.example.com",
> >             "???")
> > 
> > initiator requesting the responder for specific information, most
> > likely something that it got last time, and initiator proposes it
> > to the responder, in case it is still valid, and responder can
> > send that same information back if it is valid, or return
> > something else.
> 
> [Med] Yeah, but still this is just a suggested value and it is up to
> the responder to decide to honor it or not. If a preference does not
> make sense, the response will simply ignore it.

Yep, this is standard IKEv2 behavior. 

> > Btw, for the second use case where the initiator fills in some of
> > the information about the server it wants to talk to, it would be
> > usefull to allow Service Priority to be 0, and explictly mention
> > that this is not AliasMode, this is meaning that initiator does
> > not care about the exact priority or does not know the priority,
> > so it used 0 as placeholder.
> 
> [Med] The initiator can use any non-null value for the priority in
> such case. No need to relax the constraint imposed on svcpriority.

My guess is that people are going to use zero still, as that is the
obvious number to use, which is why I think it would be better to
allow that... As long as responders do not start checking that
CFG_REQUEST priority must be non zero everything is fine... 
-- 
[email protected]

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

Reply via email to