[Last-Call] Re: Genart last call review of draft-ietf-teas-5g-ns-ip-mpls-14

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Re-,

Please see inline. 

Cheers,
Med

> -----Message d'origine-----
> De : Lars Eggert <lars@xxxxxxxxxx>
> Envoyé : mardi 21 janvier 2025 11:00
> À : BOUCADAIR Mohamed INNOV/NET <mohamed.boucadair@xxxxxxxxxx>
> Cc : gen-art@xxxxxxxx; draft-ietf-teas-5g-ns-ip-
> mpls.all@xxxxxxxx; last-call@xxxxxxxx; teas@xxxxxxxx
> Objet : Re: Genart last call review of draft-ietf-teas-5g-ns-ip-
> mpls-14
> 
> 
> Hi,
> 
> On Jan 21, 2025, at 11:07, mohamed.boucadair@xxxxxxxxxx wrote:
> >> ### "TEAS", paragraph 1
> >>
> >> Given the importance of the figure in this I-D, it'd be nice
> if they
> >> weren't just ASCII art.
> >
> > [Med] We used to have svg figures in previous versions of the
> draft but we also had idnits complaints about Unicode characters,
> etc. As a hack, we
> reverted and tweaked many figure manually since then.
> 
> ah, I didn't know the backstory. (And idnits is unfortunately
> mostly useless these days.)
> 
> >> ### "TEAS", paragraph 1
> >> ```
> >>   A Realization of Network Slices for 5G Networks Using
> Current
> >> IP/MPLS
> >>                                Technologies
> >>                      draft-ietf-teas-5g-ns-ip-mpls-14 ```
> "Current"
> >> in the title of the doc won't age well, and doesn't actually
> convey
> >> any information. Remove?
> >
> > [Med] We prefer to keep this mention as we are leveraging
> current tools. This differentiates this document vs. "Realizing
> Network Slices in IP/MPLS Networks"
> (...) which requires extensions, new tools,
> etc.
> 
> Thanks for the background. I think the word "current" is asked to
> do way too much work if it's supposed to express all that nuance.
> Whether you leave it in or not, if you think that is an important
> distinction to draft-ietf-teas-ns-ip-mpls, the I-D needs text to
> say this.

[Med] We have this text in the introduction for that exact objective:

   The document describes a Network Slice realization approach
   that fulfills 5G slicing requirements by using existing IP/MPLS
   technologies to

and

   Rather, a key goal of the
   document is to provide pragmatic implementation approaches by
   leveraging existing readily-available, widely-deployed techniques.

Please let us know if you think we should tweak this better. Suggestions are welcome :-)

> 
> >> ### Section 11, paragraph 0
> >> ```
> >>  11.  Security Considerations
> >> ```
> >> This document describes a LOT of different schemes and
> approaches. I
> >> can't believe that only Section 4.2 warrants special
> discussion in
> >> this section?
> >> (This is probably my main question mark about this I-D.)
> >>
> >
> > [Med] We focuses on key considerations and have the following:
> >
> >   Security considerations specific to each of the technologies
> and
> >   protocols listed in the document are discussed in the
> specification
> >   documents of each of these protocols.
> 
> Right. So are you saying that no new security considerations
> arise when all these different technologies and components are
> combined in the ways explained in this document (other than what
> is said about Section 4.2)? I still find that hard to believe.
> But because Im'm not a security person, I'll leave it at that -
> you'll need to convince the SEC ADs that this is the case...

[Med] Sure. Thanks.

> 
> Thanks,
> Lars

____________________________________________________________________________________________________________
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.

-- 
last-call mailing list -- last-call@xxxxxxxx
To unsubscribe send an email to last-call-leave@xxxxxxxx




[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Mhonarc]     [Fedora Users]

  Powered by Linux