Re: [Dots] [core] WG Last Call on draft-ietf-core-new-block (No-Response)

[[e-mail]]

Re-,

Please see inline. 

Cheers,
Med

> -----Message d'origine-----
> De : Christian Amsüss [mailto:[e-mail]]
> Envoyé : mercredi 23 décembre 2020 10:52
> À : BOUCADAIR Mohamed TGI/OLN <[e-mail]>
> Cc : [e-mail]; [e-mail] WG
> ([e-mail]) <[e-mail]>; [e-mail]
> Objet : Re: [core] WG Last Call on draft-ietf-core-new-block (No-
> Response)
> 
> Hello Med,
> 
> > The text we have in the draft does not preclude No-Response (or
> any
> > solution that will be endorsed by the WG in the future):
> >
> > If both endpoints support No-Response, they can use it as a
> "signal in
> > the MAX_PAYLOADS" to trigger a 2.31 mentioned in the last
> sentence.
> >
> > As we don't recommend No-Response (for reasons echoed in your
> > message), it is not worth to include much more details on how
> > No-Response can be used.
> 
> The only reason for No-Response I echo in my mail is the downref,
> and merely showing how these can interoperate does not create a
> normative reference. It's quite a stretch to assume people would
> read "requires an additional signal" as "could use No-Response".
> 
> Working group documents time and again have outward references like
> "One way of doing this is being explored in [draft-...]", which is
> clearly non-normative, but at the same time allow the reader to get
> at least
> *some* indication of how things are meant to be used.

[Med] Simply adding a pointer would work for me. We can go for the following change: 

s/an additional signal in the MAX_PAYLOADS packet/an additional signal in the MAX_PAYLOADS packet (e.g., [RFC7967])

> 
> What makes things worse here is that as long as this specification
> does not mention No-Response at all, it is not ensured that it
> interoperates well at all with No-Response; thus even if a reader
> can make the jump, they'd have to figure out on their own that it's
> probably best if No-Response overrides the response behavior of Q-
> Block.

[Med] Here is where I disagree. As we don't recommend any solution (including No-Response), it is not up to this document to discuss how to graft the various pieces.    

> 
> >       The use of NON is thus superior but requires
> >       an additional signal in the MAX_PAYLOADS packet to seek for
> a 2.31
> >       (Continue) from the peer if it is ready to receive the next
> set of
> >       blocks.
> 
> I missed that in the part where I'm asking for whether 2.31 would be
> produced. That paragraph really opens more questions than it
> answers: If Q-Block is intended to be usable with something to
> signal that now would be a good time for a response, then this
> almost contradicts the "2.31
> (Continue) Response is not used in the current version" statement.

[Med] That statement is factual. It is meant to remind that 2.31 is legal and that it is there as a provision for any future optimization that would require it. 

> 
> Either this is a possibility already planned here, then the 2.31
> cases should be properly described, even if it's just with a "but
> requires additional signaling, which for example can be achieved by
> combining this with No-Response:0". Or it's not planned out here,
> then the 2.31 mentioned in the quoted note is more of a note on
> future updates of Q-Block that would be necessary to leverage that
> combination (but I don't see any such document happening).
> 
> Best regards
> Christian
> 
> --
> To use raw power is to make yourself infinitely vulnerable to
> greater powers.
>   -- Bene Gesserit axiom

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.